Difference between revisions of "Broadband Services Spec"
From Freeside
m |
|||
| Line 1: | Line 1: | ||
| − | + | Proposed Broadband Service Specification | |
= Introduction = | = Introduction = | ||
| Line 8: | Line 8: | ||
== svc_broadband == | == svc_broadband == | ||
| − | * layer2 | + | * 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 ==== | ||
| + | * svcnum - Primary key | ||
| + | * nasnum - Parent layer2 NAS. | ||
| + | |||
| + | Perhaps these belong in an "address" table | ||
| + | * 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 - '' | ||
| + | |||
| + | These might better be lists to cover multi-channel devices i.e. 802.1p in absence of 802.1q | ||
| + | * 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 | ||
| + | * ... | ||
| + | |||
| + | |||
| + | == NAS - Network Access Server == | ||
| + | Represents a layer2 or layer 3 provider core or edge device. The distinction between core and edge is made to show which devices can be direct parents of customer edge devices by way of svc_broadband and svc_ip. As svc_broadband represents a layer2 service/device, its parent must be a layer2 edge NAS. Similarly with svc_ip representing a layer3 service/device, its parent must be a layer3 edge NAS. However, a single NAS can serve both as a layer2 and layer3 provider edge device. | ||
| + | |||
| + | From here on, NAS refers to a layer2 NAS in the context of svc_broadband, and to a layer3 NAS in the context of svc_ip. | ||
| + | |||
| + | * Examples | ||
| + | ** Wireless AP - Layer2 provider edge NAS. | ||
| + | ** DSLAM - Layer2 provider edge NAS. | ||
| + | ** IP Router - Layer3 provider edge NAS. | ||
| + | ** Wireless AP w/ routing capabilities - Layer2 and layer3 provider edge NAS. | ||
| + | |||
| + | See Exports below for further examples and explaination. | ||
| + | === Fields === | ||
| + | * nasnum - NAS Primary key. | ||
| + | * nasparent - Parent NAS or NULL. | ||
| + | * nasip - NAS IP address. Used by exports, monitoring, etc. | ||
| + | * nasname - NAS name. | ||
| + | * nasfqdn - NAS FQDN. | ||
| + | * naslocation - NAS location. | ||
| + | * nasstreet1 - NAS street address 1. | ||
| + | * nasstreet1 - NAS street address 2. | ||
| + | * nascity - NAS city. | ||
| + | * nasstate - NAS state. | ||
| + | * naslayer2 - NAS layer2 flag, 'Y' or blank. | ||
| + | * naslayer3 - NAS layer3 flag, 'Y' or blank. | ||
| + | * nascore - NAS core flag, 'Y' or blank. | ||
| + | * nasedge - NAS edge flag, 'Y' or blank. | ||
| + | |||
| + | |||
| + | == svc_ip == | ||
| + | TODO | ||
| + | === Fields === | ||
| + | TBD | ||
| + | |||
| + | |||
| + | == Exports == | ||
| + | The real limitation in the current implementation is the lack of flexibility in the exports for broadband services. NASs, both layer2 and layer3, core and edge, need to be aware of of new, changed, and deleted services. Often, a simple child-parent relationship is insufficient to model complex networks with centralized service authentication and session management. In simple, as well as complex network configurations, this can be accomplished by allowing exports to "register" themselves with either a NAS, a service definition, or both. Exports will need to be defined for layer2 using svc_broadband and layer3 using svc_ip/svc_broadband. | ||
| + | |||
| + | === Export models === | ||
| + | The following export models define a set of conditions under which exports should run. Exports run under each model can do so in the context of a layer2 or layer3 NAS for svc_broadband or svc_ip, respectively. | ||
| + | |||
| + | ==== Global ==== | ||
| + | * Required information | ||
| + | ** nasnum - Target NAS | ||
| + | ** svcpart - Service definition. | ||
| + | |||
| + | 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 ==== | ||
| + | * Required information | ||
| + | ** nasnum - Target NAS | ||
| + | * Optional information | ||
| + | ** svcpart - Service definition | ||
| + | |||
| + | 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 parent NAS of the service that triggered the export is the NAS associated with this export. | ||
| + | * The service definition of the service that triggered the export matches the service definition associated with this export. (Optional) | ||
| + | An example of this case could be a DSLAM or a wireless access point that maintains its own ACL. | ||
| + | |||
| + | ==== Adjacent ==== | ||
| + | * Required information | ||
| + | ** nasnum - Target NAS | ||
| + | * Optional information | ||
| + | ** svcpart - Service definition* 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 parent NAS of the service that triggered the export is adjacent to the NAS associated with this export. | ||
| + | * The service definition of the service that triggered the export matches the service definition associated with this export. (Optional) | ||
| + | An example of this case could be a VRRP group or multiple wireless APs that lack a central authentication method. | ||
| + | |||
| + | ==== Child ==== | ||
| + | * Required information | ||
| + | ** nasnum - Target NAS | ||
| + | * Optional information | ||
| + | ** svcpart - Service definition | ||
| + | |||
| + | 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 NAS of the service that triggered this export is a child NAS of the NAS associated with this export. | ||
| + | * The service definition of the service that triggered the export matches the service definition associated with this export. (Optional) | ||
| + | An example of this case could be a network with one or more centralized session management NASs (eg. B-RAS[5]) that need to be updated whenever a customer is provisioned on a child NAS. | ||
| + | |||
| + | |||
| + | === Export Examples === | ||
| + | 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 layer2 customer edge device could also serve as a layer2 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. | ||
| + | |||
| + | 5 - B-RAS, Broadband Remote Access Server. The broadband version of a typical RAS/NAS with sophisticated session and QoS management capabilities. Google RedBack for examples. | ||
| + | |||
| + | --[[User:Khoff|Khoff]] 22:41, 23 May 2006 (PDT) | ||
Revision as of 15:08, 13 August 2007
Proposed Broadband Service Specification
Contents
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
- svcnum - Primary key
- nasnum - Parent layer2 NAS.
Perhaps these belong in an "address" table
- 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 -
These might better be lists to cover multi-channel devices i.e. 802.1p in absence of 802.1q
- 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
- ...
NAS - Network Access Server
Represents a layer2 or layer 3 provider core or edge device. The distinction between core and edge is made to show which devices can be direct parents of customer edge devices by way of svc_broadband and svc_ip. As svc_broadband represents a layer2 service/device, its parent must be a layer2 edge NAS. Similarly with svc_ip representing a layer3 service/device, its parent must be a layer3 edge NAS. However, a single NAS can serve both as a layer2 and layer3 provider edge device.
From here on, NAS refers to a layer2 NAS in the context of svc_broadband, and to a layer3 NAS in the context of svc_ip.
- Examples
- Wireless AP - Layer2 provider edge NAS.
- DSLAM - Layer2 provider edge NAS.
- IP Router - Layer3 provider edge NAS.
- Wireless AP w/ routing capabilities - Layer2 and layer3 provider edge NAS.
See Exports below for further examples and explaination.
Fields
- nasnum - NAS Primary key.
- nasparent - Parent NAS or NULL.
- nasip - NAS IP address. Used by exports, monitoring, etc.
- nasname - NAS name.
- nasfqdn - NAS FQDN.
- naslocation - NAS location.
- nasstreet1 - NAS street address 1.
- nasstreet1 - NAS street address 2.
- nascity - NAS city.
- nasstate - NAS state.
- naslayer2 - NAS layer2 flag, 'Y' or blank.
- naslayer3 - NAS layer3 flag, 'Y' or blank.
- nascore - NAS core flag, 'Y' or blank.
- nasedge - NAS edge flag, 'Y' or blank.
svc_ip
TODO
Fields
TBD
Exports
The real limitation in the current implementation is the lack of flexibility in the exports for broadband services. NASs, both layer2 and layer3, core and edge, need to be aware of of new, changed, and deleted services. Often, a simple child-parent relationship is insufficient to model complex networks with centralized service authentication and session management. In simple, as well as complex network configurations, this can be accomplished by allowing exports to "register" themselves with either a NAS, a service definition, or both. Exports will need to be defined for layer2 using svc_broadband and layer3 using svc_ip/svc_broadband.
Export models
The following export models define a set of conditions under which exports should run. Exports run under each model can do so in the context of a layer2 or layer3 NAS for svc_broadband or svc_ip, respectively.
Global
- Required information
- nasnum - Target NAS
- svcpart - Service definition.
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
- Required information
- nasnum - Target NAS
- Optional information
- svcpart - Service definition
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 parent NAS of the service that triggered the export is the NAS associated with this export.
- The service definition of the service that triggered the export matches the service definition associated with this export. (Optional)
An example of this case could be a DSLAM or a wireless access point that maintains its own ACL.
Adjacent
- Required information
- nasnum - Target NAS
- Optional information
- svcpart - Service definition* 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 parent NAS of the service that triggered the export is adjacent to the NAS associated with this export.
- The service definition of the service that triggered the export matches the service definition associated with this export. (Optional)
An example of this case could be a VRRP group or multiple wireless APs that lack a central authentication method.
Child
- Required information
- nasnum - Target NAS
- Optional information
- svcpart - Service definition
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 NAS of the service that triggered this export is a child NAS of the NAS associated with this export.
- The service definition of the service that triggered the export matches the service definition associated with this export. (Optional)
An example of this case could be a network with one or more centralized session management NASs (eg. B-RAS[5]) that need to be updated whenever a customer is provisioned on a child NAS.
Export Examples
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 layer2 customer edge device could also serve as a layer2 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.
5 - B-RAS, Broadband Remote Access Server. The broadband version of a typical RAS/NAS with sophisticated session and QoS management capabilities. Google RedBack for examples.
--Khoff 22:41, 23 May 2006 (PDT)
