Revision as of 13:36, 23 May 2006

Proposed Broadband Service Specification

Introduction

The intent of this document is to outline a new implementation for broadband services in Freeside. Ideally, this new implementation will be able to represent and provision arbitrarily complex network configurations.

The current support for broadband services in Freeside (svc_broadband) has a number of limitations.

svc_broadband

• layer2 & layer3 information is stored together, and cannot be separated.
• Relies on virtual fields for additional export information.

router

• No topology information.File:Example.jpg
• Represents a layer2 & layer3 provider or customer edge device.

addr_block

• Single non-hierarchical assignments to routers.

Proposed

svc_broadband

svc_broadband should store all pertinant layer1 and layer2 information for broadband services. Examples of typical layer1 services would be Wireless, DSL, T1/E1, Cable, etc. Examples of typical (possibly layered) layer2 services would be ATM, Frame Relay, Ethernet, Wireless, PPP, PPPoE, PPPoA, etc.

The emphasis is made on differentiating services at layer2, not layer1, due to the fact that many layer2 protocols (and combinations thereof) being used in the wild today are not bound to any particular layer1 protocol or physical medium. For example, 802.1x is commonly used as a layer2 authentication mechanism on 802.11 wireless networks, as well as 802.3 ethernet networks. PPPoE(oA) is an example of a combination of layer2 protocols that is widely used on DSL, Wireless, Cable, and other layer1 services. Based on these observations, and the overlap between layer2 protocols used for various layer1 services, it is recommended to take this approach rather than dividing service types based on more familiar terms like DSL, Wireless, etc.

• Represents a single layer2 service and customer/provider[1] edge device.
• Can be related to a svc_acct for authentication information when provisioning services like PPPoE, PPPoA, etc.
• Can be related to a (proposed) svc_ip for layer3 specific information.

Fields

Common

• service_address1 -
• service_address2 -
• service_city -
• service_state -
• service_country -
• contact_name -
• contact_phone1 -
• contact_phone2 -
• latitude - Common formats: DDD.MMMMM, DDD MM.MMM, DDD MM SS
• longitude -
• speed_down_mir - Downstream MIR[2].
• speed_down_cir - Downstream CIR[3].
• speed_up_mir - Upstream MIR.
• speed_up_cir - Upstream CIR. [4]
• switchnum - Parent layer2 switch.
• ...

ATM

• atm_aal - ATM Adaptation Layer (AAL[1-5]) Enumerated?
• atm_vpi - ATM Virtual Path Identifier
• atm_vci - ATM Virtual Circuit Identifier
• atm_encap - VC Mux, Ethernet over ATM LLC, Classical IP over ATM, ??? Enumerated?

Frame Relay

• fr_encap - Frame Relay Encapsulation type (IETF RFC1490/2427, Cisco) Enum?
• ft_lmi - Frame Relay LMI type (ANSI Annex D, Q933-A Annex A, Cisco) Enum?
• fr_dlci - Frame Relay Data Link Connection ID

Ethernet, IEEE 802.3

• dot3_mac_address - Ethernet MAC Address

Virtual LAN, IEEE 802.1q

• dot1q_vid - Virtual LAN Identifier
• dot1q_prio - Priority defined by IEEE 802.1p

IEEE 802.1x

• dot1x_eap_method - 802.1x EAP Method (EAP-TLS, EAP-MD5, LEAP, ...) ??? Enum?

Wireless, 802.11

• dot11_mac_address - Wireless MAC Address
• ...

switch

FIXME: switch and router need to be the same thing, but specify layer2 and/or layer3 edge. Represents a layer2 provider core or edge device. The distinction between core and edge is made to show which devices can directly interface with customer edge devices. A wireless access point or DSLAM would be examples of a layer2 provider edge device, or, edge switch using our terminology. See Exports below for a better explaination.

Fields

• ip_address - Used by exports, monitoring, etc.
• username -
• password -

TBD

router

Similar to a siwtch, a router is a layer3 provider core or edge device. The same distinction between core and edge exists.

Fields

• ip_address - Used by exports, monitoring, etc.
• username -
• password -

TBD

svc_ip

TODO

Fields

TBD

Exports

The real limitation in the current implementation is the lack of flexibility in the exports for broadband services. Provider devices, both routers and switch, core and edge, need to be aware of of new, changed, and deleted services. This can be accomplished by allowing exports to "register" themselves with either a provider device, a service definition, or both. Exports will need to be defined for layer2 using svc_broadband and switch information, as well as for layer3 using svc_ip and router information.

Export models

The following export models should exist to allow exports to be triggered for provider devices under different scenarios.

Global (part_svc)

• Required fields
  • svcpart - Service definition to match
• Required export options
  • Export host information (ie. IP address, URL, username, password, etc.)

Exports using the Global model would be triggered when a svc_broadband or svc_ip is added, changed, or deleted and the following conditions are true:

• The svcpart of the service that triggered the export matches the svcpart of the export.

An example of this case could be a centralized RADIUS server used to authenticate customer devices on a wireless access point.

Connected (router/switch, [part_svc])

• Required fields
  • switchnum (for layer2/svc_broadband exports)
  • routernum (for layer3/svc_ip exports)
  • svcpart (optional)
• Required export options
  • n/a

Exports using the Connected model would be triggered when a svc_broadband or svc_ip is added, changed, or deleted and the following conditions are true:

• The switchnum (svc_broadband) or routernum (svc_ip) of the service that triggered the export matches the switchnum or routernum, respectively, of this export.
• The svcpart of the service that triggered the export matches the svcpart of the export. (Optional)

An example of this case could be a DSLAM or a wireless access point that maintains its own ACL.

Adjacent (router/switch, [part_svc])

• Required fields
  • switchnum (for layer2/svc_broadband exports)
  • routernum (for layer3/svc_ip exports)
  • svcpart (optional)
• Required export options
  • n/a

Exports using the Adjacent model would be triggered when a svc_broadband or svc_ip is added, changed, or deleted and the following conditions are true:

• The switchnum or routernum of this export matches the switchnum or routernum of an adjacent switch or router, respectively.
• The svcpart of the service that triggered the export matches the svcpart of the export. (Optional)

An example of this case could be a VRRP group. ?

Child (router/switch, [part_svc])

• Required fields
  • switchnum (for layer2/svc_broadband exports)
  • routernum (for layer3/svc_ip exports)
  • svcpart (optional)
• Required export options
  • n/a

Exports using the Child model would be triggered when a svc_broadband or svc_ip is added, changed, or deleted and the following conditions are true:

• The parent switch or router of the service that triggered the export is a child switch or router of the switch or router that matches this export's switchnum or routernum, respectively.
• The svcpart of the service that triggered the export matches the svcpart of the export. (Optional)

An example of this case could be a DSLAM or a wireless access point that maintains its own ACL.

For example, a wireless network may have a centralized RADIUS server from which all provider edge devices authorize customer edge devices. In this case, no _layer2_ provisioning must be done directly with the provider edge devices.

TODO: More examples, diagrams.

Footnotes

1 - A l2 customer edge device could also serve as a l2 provider edge device in the case of a MDU or similar configuration. Additional svc_Broadband descendant services could potentially become "children" of this service/device in this case. Is this really a good idea, or the best way to do this???

2 - Maximum Information Rate.

3 - Committed Information Rate.

4 - If upstream MIR/CIR are zero, we assume the downstream MIR/CIR values are aggregate MIR/CIR instead of downstream only. This, of course, depends on the implementation of the export.

--Khoff 17:04, 19 May 2006 (PDT)