Difference between revisions of "Broadband Services Spec"

From Freeside
Jump to: navigation, search
(reverting spam)
 
(46 intermediate revisions by 18 users not shown)
Line 12: Line 12:
  
 
== router ==
 
== router ==
* No topology information.[[Image:Example.jpg]]
+
* 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]
* switchnum - Parent layer2 switch.
 
 
* ...
 
* ...
 +
 
==== ATM ====
 
==== ATM ====
 
* atm_aal - ATM Adaptation Layer (AAL[1-5]) Enumerated?
 
* atm_aal - ATM Adaptation Layer (AAL[1-5]) Enumerated?
Line 68: Line 75:
  
  
== switch ==
+
== NAS - Network Access Server ==
FIXME: switch and router need to be the same thing, but specify layer2 and/or layer3 edge.
+
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_ipAs 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 NASHowever, 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 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 terminologySee Exports below for a better explaination.
+
 
=== Fields ===
+
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.
* ip_address - Used by exports, monitoring, etc.
 
* username - ''
 
* password - ''
 
TBD
 
  
 +
* 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.
  
== router ==
+
See Exports below for further examples and explaination.
Similar to a siwtch, a router is a layer3 provider core or edge device.  The same distinction between core and edge exists.
 
 
=== Fields ===
 
=== Fields ===
* ip_address -  Used by exports, monitoring, etc.
+
* nasnum - NAS Primary key.
* username - ''
+
* nasparent - Parent NAS or NULL.
* password - ''
+
* nasip - NAS IP address. Used by exports, monitoring, etc.
TBD
+
* 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.  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.
+
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 exist to allow exports to be triggered for provider devices under different scenarios.
+
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.
  
==== 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:
 
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 (router/switch, [part_svc]) ====
+
==== Connected ====
* Required fields
+
* Required information
** switchnum (for layer2/svc_broadband exports)
+
** nasnum - Target NAS
** routernum (for layer3/svc_ip exports)
+
* Optional information
** svcpart (optional)
+
** svcpart - Service definition
* 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:
 
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 parent NAS of the service that triggered the export is the NAS associated with this export.
* The svcpart of the service that triggered the export matches the svcpart of the export. (Optional)
+
* 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 (router/switch, [part_svc]) ====
+
==== Adjacent ====
* Required fields
+
* Required information
** switchnum (for layer2/svc_broadband exports)
+
** nasnum - Target NAS
** routernum (for layer3/svc_ip exports)
+
* Optional information
** svcpart (optional)
+
** 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 switchnum or routernum of this export matches the switchnum or routernum of an adjacent switch or router, respectively.
+
* The parent NAS of the service that triggered the export is adjacent to the NAS associated with this export.
* The svcpart of the service that triggered the export matches the svcpart of the export. (Optional)
+
* 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
  
==== 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:
 
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 parent NAS of the service that triggered this export is a child NAS of the NAS associated with this export.
* The svcpart of the service that triggered the export matches the svcpart of the export. (Optional)
+
* 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 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 l2 customer edge device could also serve as a l2 provider edge device
+
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
+
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]] 17:04, 19 May 2006 (PDT)
+
--[[User:Khoff|Khoff]] 22:41, 23 May 2006 (PDT)

Latest revision as of 17:19, 25 July 2009

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

  • 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)