Difference between revisions of "Broadband Services Spec"
(reverting spam) |
|||
(46 intermediate revisions by 18 users not shown) | |||
Line 12: | Line 12: | ||
== router == | == router == | ||
− | * No topology information. | + | * No topology information. |
* Represents a layer2 & layer3 provider or customer edge device. | * Represents a layer2 & layer3 provider or customer edge device. | ||
== addr_block == | == addr_block == | ||
* Single non-hierarchical assignments to routers. | * Single non-hierarchical assignments to routers. | ||
− | |||
= Proposed = | = Proposed = | ||
Line 31: | Line 30: | ||
=== Fields === | === Fields === | ||
==== Common ==== | ==== Common ==== | ||
+ | * svcnum - Primary key | ||
+ | * nasnum - Parent layer2 NAS. | ||
+ | |||
+ | Perhaps these belong in an "address" table | ||
* service_address1 - | * service_address1 - | ||
* service_address2 - | * service_address2 - | ||
Line 39: | Line 42: | ||
* contact_phone1 - | * contact_phone1 - | ||
* contact_phone2 - | * contact_phone2 - | ||
+ | |||
+ | |||
* latitude - Common formats: DDD.MMMMM, DDD MM.MMM, DDD MM SS | * latitude - Common formats: DDD.MMMMM, DDD MM.MMM, DDD MM SS | ||
* longitude - '' | * 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_mir - Downstream MIR[2]. | ||
* speed_down_cir - Downstream CIR[3]. | * speed_down_cir - Downstream CIR[3]. | ||
* speed_up_mir - Upstream MIR. | * speed_up_mir - Upstream MIR. | ||
* speed_up_cir - Upstream CIR. [4] | * speed_up_cir - Upstream CIR. [4] | ||
− | |||
* ... | * ... | ||
+ | |||
==== ATM ==== | ==== ATM ==== | ||
* atm_aal - ATM Adaptation Layer (AAL[1-5]) Enumerated? | * atm_aal - ATM Adaptation Layer (AAL[1-5]) Enumerated? | ||
Line 68: | Line 75: | ||
− | == | + | == 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. | |
− | Represents a layer2 provider core or edge device. The distinction between core and edge is made to show which devices can | + | |
− | + | 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 === | === 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. | ||
Line 91: | Line 108: | ||
=== Fields === | === Fields === | ||
TBD | TBD | ||
+ | |||
== Exports == | == Exports == | ||
− | The real limitation in the current implementation is the lack of flexibility in the exports for broadband services. | + | 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 === | === Export models === | ||
− | The following export models should | + | 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: | 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. | * 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. | An example of this case could be a centralized RADIUS server used to authenticate customer devices on a wireless access point. | ||
− | ==== Connected | + | ==== Connected ==== |
− | * Required | + | * Required information |
− | ** | + | ** nasnum - Target NAS |
− | * | + | * Optional information |
− | ** svcpart | + | ** 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: | 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 | + | * The parent NAS of the service that triggered the export is the NAS associated with this export. |
− | * The | + | * 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. | An example of this case could be a DSLAM or a wireless access point that maintains its own ACL. | ||
− | ==== Adjacent | + | ==== Adjacent ==== |
− | * Required | + | * Required information |
− | ** | + | ** nasnum - Target NAS |
− | * | + | * Optional information |
− | ** svcpart | + | ** svcpart - Service definition* Required export options |
− | * Required export options | ||
** n/a | ** 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: | 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 | + | * The parent NAS of the service that triggered the export is adjacent to the NAS associated with this export. |
− | * The | + | * 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. | + | 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: | 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 | + | * The parent NAS of the service that triggered this export is a child NAS of the NAS associated with this export. |
− | * The | + | * 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 | + | 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. | 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. | ||
Line 154: | Line 170: | ||
= Footnotes = | = Footnotes = | ||
− | 1 - A | + | 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 | + | in the case of a MDU or similar configuration. Additional svc_broadband |
descendant services could potentially become "children" of this | descendant services could potentially become "children" of this | ||
service/device in this case. Is this really a good idea, or the best way | service/device in this case. Is this really a good idea, or the best way | ||
Line 168: | Line 184: | ||
on the implementation of the export. | 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]] | + | --[[User:Khoff|Khoff]] 22:41, 23 May 2006 (PDT) |
Latest revision as of 17:19, 25 July 2009
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)