Broadband Services Spec

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.
• 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]
• ...

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

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

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

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.

For example, a wireless network may have a centralized RADIUS server from which all provider edge devices authorized customer edge devices. In this case, no _layer2_ provisioning must be done directly with the provider edge devices. TODO, finish example for layer3 provisioning, mulitple cases.

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)