2. Services Overview
2.1. In This Section
This section provides an overview of the 7210 SAS-M, 7210 SAS-T,7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE-Series subscriber services, service model and service entities. Additional details on the individual subscriber services can be found in subsequent chapters.
2.2. Introduction
A service is a globally unique entity that refers to a type of connectivity service for either Internet or VPN connectivity. Each service is uniquely identified by a service ID and an optional service within a service area. The 7210 SAS-Series service model uses logical service entities to construct a service. In the service model, logical service entities provide a uniform, service-centric configuration, management, and billing model for service provisioning.
In the 7210 SAS-Series, services can provide Layer 2/bridged service between a service access point (SAP) on one router and another service access point (a SAP is where traffic enters and exits the service) on the same (local) router or another router (distributed). A distributed service spans more than one router
 | Note: SDPs are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. Only local services can be configured on 7210 SAS platforms operating in access-uplink mode. |
Distributed services use service distribution points (SDPs) to direct traffic to another 7210 SAS or SR router or other routers that supports MPLS, through a service tunnel. SDPs are created on each participating router, specifying the origination address (the router participating in the service communication) and the destination address of another router. SDPs are then bound to a specific customer service. Without the binding process, far-end router is not able to participate in the service (there is no service without associating an SDP with a service).
2.2.1. Service Types
The 7210 SAS-M, 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE: standalone and standalone-VC, and 7210 SAS-Sx 10/100GE offer the following types of subscriber services which are described in more detail in the referenced chapters:
- Virtual Leased Line (VLL) services:
- Ethernet pipe (Epipe) — A Layer 2 point-to-point VLL service for Ethernet frames. See Ethernet Pipe (Epipe) Services.
- Virtual Private LAN Service (VPLS) — A Layer 2 multipoint-to-multipoint VPN. See Virtual Private LAN Service.
- Internet Enhanced Service (IES) — A routed connectivity service used to provide IP services.This service is supported in 7210 SAS platforms operated in access-uplink mode for only inband management of the node (that is, it cannot be used as for configuring customer service in access-uplink mode). See Services Overview.
- Virtual Private Routed Network (VPRN) — A Layer 3 IP multipoint-to-multipoint VPN service as defined in RFC 2547bis. See Virtual Private Routed Network Service.
2.2.2. Service Policies
Common to all 7210 SAS-Series connectivity services are policies that are assigned to the service. Policies are defined at a global level and then applied to a service on the router. Policies are used to define 7210 SAS-Series service enhancements. The types of policies that are common to all 7210 SAS-Series connectivity services are:
- SAP Quality of Service (QoS) policies which allow for different classes of traffic within a service at SAP ingress and SAP egress.
- QoS ingress and egress policies determine the QoS characteristics for a SAP. A QoS ingress policy applied to a SAP specifies the number of meters, meter characteristics (such as forwarding class, committed, and peak information rates, etc.) and the mapping of traffic to a forwarding class. A QoS egress policy defines the queue characteristics (such as CBS, CIR, PIR). A QoS policy must be created before it can be applied to a SAP. A single ingress and egress QoS policy can be associated with a SAP. A single access egress QoS policy can be associated with a port.
- Filter policies allow selective blocking of traffic matching criteria from ingressing or egressing a SAP.Filter policies, also referred to as access control lists (ACLs), control the traffic allowed in or out of a SAP based on MAC or IP match criteria. Associating a filter policy on a SAP is optional. Filter policies are identified by a unique filter policy ID. A filter policy must be created before it can be applied to a SAP. A single ingress and single egress filter policy can be associated with a SAP.
- Scheduler policies define the operating parameters (such as scheduling algorithm, weights per priority). Depending on the platform, these are either associated with SAPs or physical ports.
- Accounting policies define how to count the traffic usage for a service for billing purposes.The routers provide a comprehensive set of service-related counters. Accounting data can be collected on a per-service, per-forwarding class basis, which enables network operators to accurately measure network usage and bill each customer for each individual service using any of a number of different billing models.
2.3. Nokia Service Model
In the Nokia service model, the service edge routers are deployed at the provider edge. Services are provisioned on the service routers and transported across an IP and/or IP/MPLS provider core network in encapsulation tunnels created using MPLS label switched paths (LSPs).
The 7210 SAS devices configured in access-uplink mode supports QinQ/Dot1q Layer 2 uplinks to transport the services to the provider edge in a hierarchical configuration, whereas 7210 SAS devices configured in network mode support MPLS uplinks to transport the services.
The service model uses logical service entities to construct a service. The logical service entities are designed to provide a uniform, service-centric configuration, management, and billing model for service provisioning. Some benefits of this service-centric design include:
- Many services can be bound to a single customer.
- QoS policies, filter policies, and accounting policies are applied to each service instead of correlating parameters and statistics from ports to customers to services.
Service provisioning uses logical entities to provision a service where additional properties can be configured for bandwidth provisioning, QoS, security filtering, accounting/billing to the appropriate entity.
2.4. Service Entities
Figure 1 shows the basic logical entities in the service model used to construct a service.
Figure 1: Service Entities for 7210 SAS devices configured in Network Mode
2.4.1. Customers
The terms customers and subscribers are used synonymously. The most basic required entity is the customer ID value which is assigned when the customer account is created. To provision a service, a customer ID must be associated with the service at the time of service creation.
2.4.2. Service Access Points (SAPs)
Each subscriber service type is configured with at least one service access point (SAP). A SAP identifies the customer interface point for a service on a Nokia 7210 SAS router (Figure 2). The SAP configuration requires that slot, MDA, and port information be specified. The slot, MDA, and port parameters must be configured before provisioning a service (see the Cards, MDAs, and Ports sections of the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide).
A SAP is a local entity to the router and is uniquely identified by:
- The physical Ethernet port
- The encapsulation type
- The encapsulation identifier (ID)
Depending on the encapsulation, a physical port can have more than one SAP associated with it. SAPs can only be created on ports designated as “access” in the physical port configuration.
Figure 2 shows a SAP used for customer service delivery with SDP used for service transport on 7210 SAS devices that support MPLS uplinks (also known as, network mode platforms).
Figure 2: Service Access Point (SAP) for 7210 SAS configured in Network Mode
The Figure 3 shows a SAP used for customer service delivery with access-uplink SAPs (also known as, QinQ SAPs) used for service transport on 7210 SAS devices that support only L2 uplinks (also known as, access-uplink mode platforms).
Figure 3: Multiple SAPs in a Service Using QinQ Uplinks in 7210 SAS Configured in Access-uplink Mode
2.4.2.1. SAP Encapsulation Types and Identifiers
The encapsulation type is an access property of a service Ethernet port. The appropriate encapsulation type for the port depends on the requirements to support multiple services on a single port on the associated SAP and the capabilities of the downstream equipment connected to the port. For example, a port can be tagged with IEEE 802.1Q (referred to as dot1q) encapsulation in which each individual tag can be identified with a service. A SAP is created on a specific port by identifying the service with a specific encapsulation ID.
2.4.2.2. Ethernet Encapsulations
The following are the encapsulation service options on Ethernet ports:
- Null — Supports a single service on the port. For example, where a single customer with a single service customer edge (CE) device is attached to the port. The encapsulation ID is always 0 (zero).
- Dot1q — Supports multiple services for one customer or services for multiple customers (Figure 4). The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header. For example, the port is connected to a Ethernet switch with multiple downstream customers.
- QinQ — The QinQ encapsulation type adds a IEEE 802.1Q tag to the 802.1Q tagged packets entering the network to expand the VLAN space by tagging tagged packets, producing a double tagged frame. 7210 SAS OS supports QinQ encapsulation for access ports in network mode. In access-uplink mode, QinQ encapsulation is supported for both access port and access uplink ports.
The following are the encapsulation service options on Ethernet access uplink ports:
- QinQ — The QinQ encapsulation type adds a IEEE 802.1Q tag to the 802.1Q tagged packets entering the network to expand the VLAN space by tagging tagged packets, producing a double tagged frame.
Figure 4 shows multiple SAPs used for customer service delivery on the same port and belonging to the same service, along with SDP used for service transport on 7210 SAS devices that support MPLS uplinks (also known as, network mode platforms). This is supported only in network mode.
Figure 4: Multiple SAPs on a Single Port (7210 in Network Mode)
2.4.2.3. Services and SAP Encapsulations
Table 5 lists the service and SAP Encapsulation information for Ethernet ports:
Table 5: Service and Encapsulation
Port Type | Encapsulation |
Ethernet | Null |
Ethernet | Dot1q |
Ethernet | QinQ |
2.4.2.4. Default SAP on a Dot1q Port
This feature introduces default SAP functionality on Dot1q-encapsulated ports. On a dot1q-encapsulated port where a default SAP is configured, all packets with q-tags not matching any explicitly defined SAPs will be assigned to this SAP. SAPs with default Dot1q encapsulation are supported in VPLS and Epipe services. Dot1q Default SAP are not supported in VPRNs. In this context, the character “*” indicates default which means allow through. The default SAP also accepts untagged or priority tagged packets. A default SAP must be configured explicitly. When a default SAP is not configured explicitly, packets not matching any explicitly defined SAPs will be dropped.
One of the applications where this feature can be applicable is an access connection of a customer who uses the whole port to access Layer 2 services. The internal VLAN tags are transparent to the service provider. This can be provided by a null encapsulated port.
In this type of environment, logically two SAPs exist, a management SAP and a service SAP. The management SAP can be created by specifying a VLAN tag which is reserved to manage the CPE. The service SAP covers all other VLANs and behaves as a SAP on a null-encapsulated port.
There a few constraints related for the use of default SAP on a Dot1q-encapsulated port:
- This type of SAP is supported only on VPLS and Epipe services and cannot be created in IES and VPRN services as it cannot preserve VLAN tag markings.
- For VPLS SAPs with STP enabled, STP listens to untagged and null-tagged BPDUs only. All other tagged BPDUs are forwarded like other customer packets. This is the same behavior as null-encapsulated ports.
- This type of SAP is mutually exclusive with a SAP defined by explicit null encapsulation (for example, 1/1/1:0). This avoids conflict as to which SAP untagged frames should be associated.
- IGMP snooping is not supported on a default SAP. This would require remembering VLAN tags per hosts. By not allowing IGMP snooping of this SAP, all IGMP packets will be transparently forwarded.
2.4.2.5. Default SAPs on a QinQ Port (supported only on 7210 SAS devices configured in access-uplink mode)
Default QinQ SAPs (notation - *.*) are used in ring ports to avoid the need to configure services on all the intermediate nodes in the ring which are transiting the service. Default QinQ SAPs matches all VLAN tagged traffic which is not classified into any other SAP configured on the same port. Only one EPIPE service with default QinQ SAPs is needed for transit service traffic on access-uplink ports. Default QinQ SAPs are allowed only on access-uplink ports and access ports. It can co-exist with 0.* SAP on an access-uplink or access port. A default QinQ SAP accepts only tagged packets. Untagged packets or priority tagged packets are not accepted on Default QinQ SAPs.
When an EPIPE service With default QinQ SAPs on the ring ports is used for transit traffic in a ring deployment, no protection mechanism (example: STP or G.8032) is supported for Default QinQ SAPs. The upstream or head-end node on which the service originates must ensure the correct path on the ring is selected using either G.8032 or STP. When a VPLS service with default QinQ SAPs on the ring ports is used for transit traffic in a ring deployment, users can use either G.8032 or M-VPLS with xSTP for ring protection. When using G.8032, the state of the default QinQ SAPs in the VPLS service can be managed using a separate G.8032 control instance.
| Note: G.8032 control instance cannot use Default QinQ SAPs. |
Default QinQ SAP is available for use only in an EPIPE and a VPLS service created with svc-sap-type parameter set to "null-star". Default QinQ SAP can be configured along with other SAPs allowed in the same service (that is, service with svc-sap-type parameter set to "null-star").
Following features are available for use with Default QinQ SAPs configured in Epipe and VPLS service (unless explicitly specified, the following features are applicable for both Epipe and VPLS service):
For Default QinQ SAPs on either access ports or access-uplink ports:
- MAC learning and aging is available for use in a VPLS service
- Per SAP MAC limit is available for use in a VPLS service
- Mac-move detection and Mac-pinning is available for use in a VPLS service
- Discard-unknown and discard-unknown-source is available for use in a VPLS service
- ETH-CFM and Y.1731 is not available for use
- STP (and all its different flavors) cannot be enabled in the service with Default QinQ SAPs
- MVPLS with xSTP can be used for loop prevention. The Default QinQ SAPs inherit the state from the associated MVPLS instance.
- G.8032 control instance cannot be configured in a service with Default QinQ SAP
- G.8032 can be used for loop prevention in ring deployments, where the Default QinQ SAPs are configured on the ring ports in a VPLS service. A separate G.8032 control instances needs to be configured for use on the ring ports and the service with Default QinQ ports needs to be associated with this G.8032 control instance
- IGMP snooping is not available for use
- L2PT and BPDU translation is not available for use
- IP interface in a VPLS service is not supported in a service using this SAP
For Default QinQ SAPs created on Access-uplink Port:
- Ingress QoS policy applied on an access uplink port is available for classification and policing on ingress.
- Egress QoS policy applied on an access uplink port is available for egress queue shaping, scheduling and marking.
- SAP Ingress ACLs are available for use
- SAP Egress ACLs are not available for use
- SAP Ingress received count and SAP Egress forwarded count are available for use (appropriate accounting records can be used)
For Default QinQ SAPs created on access ports:
- SAP ingress QoS policy is available for use
- Egress QoS policy applied on an access port is available for egress shaping, scheduling and marking.
- SAP Ingress ACLs are available for use
- SAP egress ACLs are not available for use
- SAP Ingress Meter counters, SAP Ingress received count and SAP Egress forwarded counter are available for use (appropriate accounting records can be used)
2.4.2.5.1. Configuration Notes for use of Default QinQ SAPs for transit service in a ring deployment
- If an Epipe service is used with Default QinQ SAPs on the ring ports for transit service in a ring deployment, no protection mechanism is available for the transit service (that is, Epipe service with the Default QinQ SAPs on ring ports). Both Epipe and VPLS services which are originating on different nodes in the ring can use the transit service. Protection/Loop-detection mechanisms can be implemented for VPLS service configured in the ring nodes, by using MVPLS with xSTP on the nodes where the VPLS service is configured. No protection mechanisms are available for use with Epipe services on the node that originates the service.
- If a VPLS service is used with Default QinQ SAPs on the ring ports for transit service in a ring deployment, either MVPLS/xSTP or G.8032 can be used to protect the transit service (that is, VPLS service with the Default QinQ SAPs on ring ports). In this case, VPLS service which are originating on different nodes in the ring and use the transit VPLS service are also protected. Epipe services which are originating on different nodes in the ring cannot use the transit VPLS service.
- When using VPLS service with Default QinQ SAPs for transit service with either G.8032 or MVPLS with xSTP configured for protection, load-balancing of the traffic based on the VLAN IDs is not possible. If load-balancing is desired then it is better to use Epipe service with Default QinQ SAPs as the transit service.
2.4.2.6. SAP Configuration Considerations (applicable for both Network mode and access-uplink mode)
When configuring a SAP, consider the following (applicable to both network mode and access-uplink mode):
- A SAP is a local entity and only locally unique to a specific device. The same SAP ID value can be used on another 7210 SAS-Series.
- There are no default SAPs configured on the node. All SAPs in subscriber services must be created.
- The default administrative state for a SAP at creation time is administratively enabled.
- When a SAP is deleted, all configuration parameters for the SAP will also be deleted.
- A SAP is owned by and associated with the service in which it is created in each router.
- A port with a dot1q encapsulation type means the traffic for the SAP is identified based on a specific IEEE 802.1Q VLAN ID value. The VLAN ID is stripped off at SAP ingress and the appropriate VLAN ID placed on at SAP egress. As a result, VLAN IDs only have local significance, so the VLAN IDs for the SAPs for a service need not be the same at each SAP.
- If a port is administratively shutdown, all SAPs on that port will be operationally out of service.
- QinQ access SAPs of type Q1.0 is not supported.
- A SAP cannot be deleted until it has been administratively disabled (shutdown).
- Each SAP can have one each of the following policies assigned:
- Ingress filter policy
- Egress filter policy
- Ingress QoS policy
- Accounting policy
2.4.2.7. SAP configuration notes when operating the 7210 SAS devices in network mode only
When provisioned in network mode, the following SAP configuration guidelines are applicable.
Table 6 describes details of SAP and service (svc-sap-type) combinations for Layer 2 services (when in network mode).
Table 6: SAP and service (svc-sap-type) combinations for Layer 2 services (when in network mode)
svc-sap-type (Layer 2 service) | Access SAPs | SDP Bindings |
Any (without any QinQ SAP in the same service) | NULL SAP, Dot1q SAP, Dot1q Default SAP, Dot1q Explicit NULL SAP, Q1.* SAP, 0.* SAP (accepts only untagged frames) | PW with vc-type set to vc-ether or vc-vlan |
Any (with QinQ SAP in the same service) | NULL SAP (accepts only untagged frames), Dot1q SAP (accepts only a single tag frame, Dot1q Explicit NULL SAP (accepts only untagged frame), Q1.Q2 SAP (accepts frames with only two tags), 0.* SAP (accepts only untagged frames) | PW with vc-type set to vc-ether or vc-vlan (accepts only untagged frames on vc-ether PW and only tagged frames on vc-vlan PW) |
Any (with dot1q-range SAP) | Dot1q range SAP, Q1.* SAP | PW with vc-type set to vc-ether or vc-vlan (no checks on VLAN ID for packets received on PW). |
Qinq-inner-tag-preserve | Q1.Q2 SAP (inner tag Q1 is not stripped), Dot1q SAP (no tags is stripped) | PW with vc-vlan (vc-vlan is not stripped) |
2.4.2.8. QinQ SAP Configuration Restrictions for 7210 SAS Platforms in Network Operating Mode
The following are the QinQ access SAP configuration guidelines for 7210 SAS in Network mode only.
These guidelines are not applicable when the 7210 SAS-M devices are configured in access uplink mode and access uplink SAPs are in use.
- Processing of tagged packets received on SAPs configured in a service in which a QinQ SAP is also in use (not applicable when a QinQ SAP is not provisioned in a service).
- When a QinQ SAP is configured in a service, the number of VLAN tags in the packets received on NULL SAP, Dot1q SAP and QinQ SAP configured in the same service should match the number of VLAN tags implied by the port encapsulation mode. Packets that do not match are dropped by the hardware. That is, packets received with more than two VLAN tags on a QinQ SAP are dropped, packets received with more than one VLAN tag on a Dot1q SAP are dropped and packets received with tags (even packet with a priority tag) on a NULL SAP are dropped. Henceforth in this document, such packets are referred to as extra-tag packets.
- When a QinQ SAP is configured in a service, the number of VLAN tags in the packets received on the VC/pseudowire of type ‘vc-vlan’ should be exactly one and packets received on the VC/pseudowire of type ‘vc-ether’ should contain no tags (not even priority tag). If either case, packets that contain more number of VLAN tags than the number mentioned previously are dropped. Henceforth the document refers to such packets as extra-tag packets.
- The system will provide a limited amount of counters to count the number of extra-tag packets dropped on SAP ingress. These counters are intended for diagnostic use.Table 7 shows the SAP types allowed in a service when QinQ SAP is in use.
Table 7: SAP types in a service when QinQ SAP is in use (Network mode operation)
SAP configured in the service
SAPs Not Allowed for configuration in the same service
QinQ
Q.* SAP, Dot1q Default SAP
Q.*
Q1.Q2
Dotq1 default SAP
Q1.Q2
0.* QinQ SAP configured in the service will accept only untagged or priority tagged packets, irrespective of whether a QinQ SAP is configured in the service or not.
| Note: 7210 SAS platforms support a mechanism to transport QinQ packets in an Epipe with 2 or more tags, with some restrictions. For more information, see Ethernet Pipe (Epipe) Services. |
2.4.2.9. SAP Configuration Notes for 7210 SAS Platforms in Access-Uplink Operating Mode
When provisioned in access-uplink mode, the following SAP configuration guidelines are applicable.
Table 8 describes SAP and service combinations allowed in access-uplink mode.
Table 8: SAP and Service Combinations for 7210 SAS-M and 7210 SAS-T in Access-uplink Mode
svc-sap-type | Access SAPs | Access Uplink SAPs |
null-star | Null SAP,dot1q Default SAP, Default QinQ SAP (*.* SAP) | Q.* SAP, Default QinQ SAP (*.* SAP) |
dot1q-preserve | dot1q SAP (dot1q VLAN tag is not stripped on ingress) Q1.Q2 SAP (Q2 tag VLAN ID must match the dot1q SAP VLAN ID) | Q1.Q2 SAP (Q2 tag VLAN ID must match the dot1q SAP VLAN ID) |
any | dot1q SAP Null SAP, dot1q SAP, dot1q explicit null SAP, Q1.Q2 SAP, Q.* SAP, 0.* SAP | Q1.Q2 SAP, Q.* SAP, 0.* SAP |
dot1q-range | dot1q SAP (dot1q VLAN tag not stripped on ingress), Q1.* SAP | Q1.* SAP |
- ‘svc-sap-type’ parameter value determines the type of SAPs that are allowed to be provisioned in a service.
- A physical port can have only one SAP to be part of one service. Multiple SAPS can be defined over a physical port but each of these SAPs should belong to a different service.
- In the case of a service sap-type is specified as dot1q-preserve, all the SAPs configured in the service must have the same VLAN ID. The outermost VLAN tag of the packets received on access port is not stripped, when svc-sap-type is set to dot1q-preserve.
- Dot1q Default SAP cannot be configured when svc-sap-type is set to ‘any’
- When svc-sap-type is set to ‘any’ for a NULL SAP, the system processes and forwards only packets with no VLAN tag (that is, untagged). All other packets with one or more VLAN tags (even those with priority tag only) are not processed and dropped. Users can use the service with svc-sap-type set to ‘null-star’, to process and forward packets with one or more tags (including priority tag) on a null SAP.
- An ingress QoS policy and accounting policy is assigned per access uplink port and cannot be assigned per access uplink SAP.
- The Default QinQ SAP processes only tagged packets received on a QinQ port. All tagged packets that do not match the specific SAP tags configured on the same port are processed by this SAP. The Default QinQ SAP cannot process un-tagged packets, even if 0.* SAP is not configured for use on that port.
- The Default QinQ SAPs is available for use with 0.* SAPs configured on the same port or in the same service. It is available for use with another default QinQ SAP configured in the same service (on a different port).In a VPLS service, the Default QinQ SAP is available for use with any other SAP type configured in a service configured with svc-sap-type parameter set to "null-star".
- SAPs using connection-profile (to specify dot1q VLAN ranges or individual VLAN IDs) can be configured in a service only when svc-sap-type is set to 'dot1q-range'.
- When a service is configured to use svc-sap-type 'dot1q-range', the outermost V-LAN tag of the packets are not stripped when the packet is received on access port ingress. For more information, see “Ethernet Pipe (Epipe) Services” chapter for processing behavior for this type of service.
2.4.3. Service Distribution Points (SDPs)
| Note: SDPs are supported by all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. |
A service distribution point (SDP) acts as a logical way to direct traffic from one router to another through a uni-directional (one-way) service tunnel. The SDP terminates at the far-end device which directs packets to the correct service egress SAPs on that device. A distributed service consists of a configuration with at least one SAP on a local node, one SAP on a remote node, and an SDP binding the service to the service tunnel.
An SDP has the following characteristics:
- An SDP is locally unique to a participating routers. The same SDP ID can appear on other 7210 SAS-Series routers.
- An SDP uses the system IP address to identify the far-end edge router.
- An SDP is not specific to any one service or any type of service. When an SDP is created, services are bound to the SDP. An SDP can also have more than one service type associated with it.
- All services mapped to an SDP use the same transport encapsulation type defined for the SDP.
- An SDP is a management entity. Even though the SDP configuration and the services carried within are independent, they are related objects. Operations on the SDP affect all the services associated with the SDP. For example, the operational and administrative state of an SDP controls the state of services bound to the SDP.
An SDP from the local device to a far-end router requires a return path SDP from the far-end 7210 SAS-Series back to the local router. Each device must have an SDP defined for every remote router to which it needs to provide service. SDPs must be created first, before a distributed service can be configured.
2.4.3.1. SDP Binding
Figure 5 shows an example of SDP binding. To configure a distributed service from ALA-A to ALA-B, SDP ID (1) must be specified in the service creation process to “bind” the service to the tunnel (the SDP). Otherwise, service traffic is not directed to a far-end point and the far-end devices cannot participate in the service (there is no service). To configure a distributed service from ALA-B to ALA-A, SDP ID (5) must be specified.
Figure 5: MPLS Service Distribution Point (SDP) Pointing From ALA-A to ALA-B
2.4.3.2. Spoke and MESH SDPs
| Note: SDPs are supported by all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. |
When an SDP is bound to a service, it is bound as either a spoke-SDP or a mesh SDP. The type of SDP indicates how flooded traffic is transmitted. The 7210 SAS Network Mode devices supports both spoke and mesh SDPs.
A spoke-SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke-SDP is replicated on all other “ports” and not transmitted on the port it was received.
All mesh SDPs bound to a service are logically treated like a single bridge “port” for flooded traffic where flooded traffic received on any mesh SDP on the service is replicated to other “ports” (spoke-SDPs and SAPs) and not transmitted on any mesh SDPs.
2.4.3.3. SDP Using BGP Route Tunnel
SDP is enhanced to use BGP route tunnel to extend inter-AS support for Layer 2 and Layer 3 VPN services. An SDP can be configured to use MPLS transport method. MPLS SDP support is enhanced to allow a BGP route tunnel to reach the far-end PE. A single method of tunneling is allowed per SDP (for example, LDP, RSVP-TE LSP or BGP route tunnel). BGP route tunnel method is excluded if multi-mode transport is enabled for an SDP.
For inter-AS far-end PE, next-hop for BGP route tunnel must be one of the local ASBR. The LSP type selected to reach the local ASBR (BGP labeled route next-hop) must be configured under the BGP global context. LDP must be supported to provide transport LSP to reach the BGP route tunnel next-hop.
Only BGP route labels can be used to transition from ASBR to the next-hop ASBR. The global BGP route tunnel transport configuration option must be entered to select an LSP to reach the PE node from ASBR node. On the last BGP segment, both “BGP+LDP” and LDP routes may be available to reach the far-end PE from the ASBR node. LDP LSP must be preferred due to higher protocol priority. This leads to just one label besides other labels in stack to identify VC/VPN at far-end PE nodes.
2.4.3.4. SDP Keepalives
SDP keepalives actively monitor the SDP operational state using periodic Nokia SDP ping echo request and echo reply messages. SDP ping is a part of the Nokia suite of service diagnostics built on a Nokia service-level OA&M protocol. When SDP ping is used in the SDP keepalive application, the SDP echo request and echo reply messages are a mechanism for exchanging far-end SDP status.
Configuring SDP keepalives on a specific SDP is optional. SDP keepalives for a particular SDP have the following configurable parameters:
- Admin up/admin down state
- Hello time
- Message length
- Max drop count
- Hold down time
SDP keepalive echo request messages are only sent when the SDP is completely configured and administratively up and SDP keepalives is administratively up. If the SDP is administratively down, keepalives for the SDP are disabled.
SDP keepalive echo request messages are sent out periodically based on the configured Hello Time. An optional message length for the echo request can be configured. If max drop count echo request messages do not receive an echo reply, the SDP will immediately be brought operationally down.
If a keepalive response is received that indicates an error condition, the SDP will immediately be brought operationally down.
When a response is received that indicates the error has cleared and the hold down time interval has expired, the SDP will be eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP will enter the operational state.
For information about configuring keepalive parameters, refer to Configuring an SDP.
2.4.3.5. Mixed-LSP Mode of Operation
The mixed LSP SDP allows for a maximum of two LSP types to be configured within an SDP. A primary LSP type and a backup LSP type. An RSVP primary LSP type can be backed up by an LDP LSP type.
An LDP LSP can be configured as a primary LSP type which can then be backed up by a BGP LSP type.
At any time, the service manager programs only one type of LSP in the line card that will activate it to forward service packets according to the following priority order:
- RSVP LSP type. One RSVP LSP can be configured per SDP. This is the highest priority LSP type.
- LDP LSP type. One LDP FEC will be used per SDP. 7210 SAS does not support LDP ECMP.
- BGP LSP type. One RFC 3107-labeled BGP prefix programmed by the service manager.
In the case of the RSVP/LDP SDP, the service manager will program the NHLFEs for the active LSP type preferring the RSVP LSP type over the LDP LSP type. If no RSVP LSP is configured or all configured RSVP LSPs go down, the service manager will reprogram the line card with the LDP LSP if available. If not, the SDP goes operationally down.
When a higher priority type LSP becomes available, the service manager reverts to this LSP at the expiry of the revert-time timer or the failure of the currently active LSP, whichever comes first. The service manager then reprograms the line card accordingly. If the infinite value is configured, the SDP reverts to the highest priority type LSP only if the currently active LSP failed.
| Note: LDP uses a tunnel down damp timer that is set to three seconds by default. If the LDP LSP fails, the SDP reverts to the RSVP LSP type after the timer expires. For an immediate switchover, the timer should be set to zero using the configure>router>ldp>tunnel-down-damp-time command. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S MPLS Guide for more information. |
If the value of the revert-time timer is changed, it comes into effect only at the next use of the timer. Any timer that is outstanding at the time of the change is restarted with the new value.
In the case of the LDP/BGP SDP, the service manager prefers the LDP LSP type over the BGP LSP type. The service manager reprograms the line card with the BGP LSP, if available; otherwise the SDP is placed in the operationally down state.
| Note: An LDP/BGP SDP has differences in behavior compared to an RSVP/LDP SDP. For a specific /32 prefix, only a single route will exist in the routing table: the IGP route or the BGP route. Therefore, either the LDP FEC or the BGP label route is active at any time. As a result, the tunnel table needs to be reprogrammed each time a route is deactivated and another is activated. Also, the SDP revert-time cannot be used as there is no situation where both LSP types are active for the same /32 prefix. |
2.4.4. SAP and Service Scaling with High SAP Scale Mode on 7210 SAS-Mxp
In L2 access networks, used to backhaul service traffic from business services, mobile backhaul, and residential services, the 7210 SAS-Mxp acts as an L2 carrier Ethernet switching platform with VLAN-based L2 uplinks. To perform this role, the 7210 SAS-Mxp must support a mode that is similar to the access-uplink operating mode available on 7210 SAS-M, with higher SAP and service scaling. To do so, the 7210 SAS-Mxp uses the SAP scale mode and port-based access ingress policies.
| Note: Unlike on the 7210 SAS-M and 7210 SAS-T, on the 7210 SAS-Mxp sap-scale-mode can be configured in standalone mode and does not require a BOF configuration. |
Figure 6 shows the use of L2 uplinks in an L2 access network with a 7210 SAS-Mxp.
Figure 6: 7210 SAS-Mxp Using L2 Uplinks in an L2 Network
The SAP scale mode is configured using the configure>system>resource-profile>sap-scale-mode {high | low} command. By default, the low option is configured for low SAP scale mode, which provides backward compatibility. The user can configure the high option to use high SAP scale mode, which allows the configuration of a higher number of services and SAPs. Before changing the sap-scale-mode value, the user must perform the following:
- remove all service and SAP configurations
- change the value of sap-scale-mode and enable per-port egress queuing using the configure>system>resource-profile>qos>port-scheduler-mode command
- reboot the node
- reconfigure all SAPs and services as required
In the high SAP scale mode, the system supports higher SAP and service scaling for Epipe/VLL and VPLS services only. SAP and service scaling for IES, VPRN, and RVPLS services remain unchanged.
QoS policies support port-based access ingress policies on access ports to facilitate the use of access ports as L2 uplinks. With the use of ports as L2 uplinks, the user can apply a single port-based access ingress policy at ingress of an access port, instead of using per-SAP ingress policies. This allows a single policy definition to be used to classify and rate-limit all traffic received over access ports used as L2 uplinks (similar to a network port-based policy applied to network ports used as uplinks) instead of using per SAP ingress policies. Resources must be allocated using the configure>system>resource-profile command to use access ingress QoS policies on an access port.
In addition, only the following QoS policies can be used in the high SAP scale mode to achieve a higher scale:
- Access port-based egress queuing and shaping on all ports, including service delivery ports and uplinks
- Access port-based ingress classification and policing on uplinks
- Epipe and VPLS SAPs using ingress table-based classification and policing on service delivery ports for higher SAP scale
- IES and VPRN SAPs using table-based classification or CAM-based classification
- RVPLS SAPs using CAM-based classification and policing
- default SAP ingress QoS policy of 65536
The following SAP configuration restrictions apply to the high SAP scale mode; see section 2.4.2 for additional SAP configuration guidelines.
- If an RVPLS Q1.* SAP is configured, SAPs (Q1.Q2 SAP) with a matching Q1 tag cannot be configured in other VPLS, Epipe, IES, and VPRN services on the same port.
- If a VPLS Q1.* SAP enabled with DHCP snooping is configured, SAPs (Q1.Q2 SAP) with a matching Q1 tag cannot be configured in other VPLS, Epipe, IES, and VPRN services on the same port. They can use other values for the Q1 tag. The reverse is also true.
- The dot1p default SAP cannot be configured in RVPLS services; it is only supported in Epipe, VPLS, IES, and VPRN services.
2.4.4.1. Configuration Guidelines
This section describes the guidelines to configure SAP and service scaling.
2.4.4.1.1. Guidelines for Configuring High SAP Scale Mode
Perform the following procedure to change the sap-scale-mode low to the sap-scale-mode high configuration.
- Delete all SAPs.
- Configure the config>system>resource-profile>qos>port-scheduler-mode command.
- Configure the sap-scale-mode command to use the high option.
- Save the configuration and reboot the node.
2.4.4.1.2. Guidelines for Configuring Low SAP Scale Mode
Perform the following procedure to change the sap-scale-mode high to the sap-scale-mode low configuration.
- Delete all SAP.
- If the access ingress QoS policy has attachments, reset the policy.
- If the access-ingress-qos-mode command is set to port-mode, configure the command to use the sap-mode option.
- Configure the sap-scale-mode command to use the low option.
- Save the configuration and reboot the node.
2.4.5. G.8032 Ethernet Ring Protection Switching
Ethernet ring protection switching provides ITU-T G.8032 specification compliance to achieve resiliency for Ethernet Layer 2 networks. Similar to G.8031 linear protection (also called Automatic Protection Switching (APS)), G.8032 (Eth-ring) is built on Ethernet OAM and often referred to as Ring Automatic Protection Switching (R-APS).
Eth-rings are supported on VPLS SAPs. VPLS services supporting Rings SAPs can connect to other rings and Ethernet service using VPLS, and R-VPLS SAPs. Eth-rings enables rings for core network or access network resiliency. A single point of interconnection to other services is supported. The Eth-ring service is a VLAN service providing protection for ring topologies and the ability to interact with other protection mechanisms for overall service protection. This ensures failures detected by Eth-ring only result in R-APS switchover when the lower layer cannot recover and that higher layers are isolated from the failure.
Rings are preferred in data networks where the native connectivity is laid out in a ring or there is a requirement for simple resilient LAN services. Due to the symmetry and the simple topology, rings are viewed a good solution for access and core networks where resilient LANS are required. The Nokia implementation can be used for interconnecting access rings and to provide traffic engineered backbone rings. The 7210 SAS implementation of G.8032 supports dual inter-connected rings with sub-rings.
Eth-rings use one VID per control per ring instance and use one (typically) or multiple VIDs for data instances per control instance. A dedicated control VLAN (ERP VLAN) is used to run the protocol on the control VID. G.8032 controls the active state for the data VLANs (ring data instances) associated with a control instance. Multiple control instances allow logically separate rings on the same topology. The Nokia implementation supports dot1q, and qinq encapsulation for data ring instances. The control channel supports dot1q and qinq encapsulation.
2.4.5.1. Overview of G.8032 Operation
R-APS messages that carry the G.8032 protocol are sent on dedicated protocol VLAN called ERP VLAN (or Ring Control Instance). In a revertive case, G.8032 Protocol ensures that one Ring Protection Link (RPL) owner blocks the RPL link. R-APS messages are periodically sent around in both directions to inform other nodes in the Ring about the blocked port in the RPL owner node. In non-revertive mode any link may be the RPL link.Y.1731 Ethernet OAM CC is the basis of the RAPs messages. Y.1731 CC messages are typically used by nodes in the ring to monitor the health of each link in the ring in both directions. However CC messages are not mandatory. Other link layer mechanisms could be considered – for example LOS (Loss of Signal) when the nodes are directly connected.
Initially each Ring Node blocks one of its links and notifies other nodes in the ring about the blocked link. When a ring node in the ring learns that another link is blocked, the node unblocks its blocked link possibly causing FDB flush in all links of the ring for the affected service VLANs, controlled by the ring control instance. This procedure results in unblocking all links but the one link and the ring normal (or idle) state is reached. In revertive mode the RPL link will be the link that is blocked when all links are operable after the revert time. In non-revertive mode the RPL link is no different that other ring links. Revertive mode provides predictability particularly when there are multiple ring instances and the operator can control which links are block on the different instances. Each time there is a topology change that affects reachability, the nodes may flush the FDB and MAC learning takes place for the affected service VLANs, allowing forwarding of packets to continue. Figure 7 shows this operational state.
Figure 7: G.8032 Ring in the Initial State
When a ring failure occurs, a node or nodes detecting the failure (enabled by Y.1731 OAM CC monitoring) send R-APS message in both directions. This allows the nodes at both ends of the failed link to block forwarding to the failed link preventing it from becoming active. In revertive mode, the RPL Owner then unblocks the previously blocked RPL and triggers FDB flush for all nodes for the affected service instances. The ring is now in protecting state and full ring connectivity is restored. MAC learning takes place to allow Layer 2 packet forwarding on a ring. Figure 8 shows the failed link scenario.
Figure 8: 0-1 G.8032 Ring in the Protecting State
When the failed link recovers, the nodes that blocked the link again send the R-APS messages indicating no failure this time. This in turn triggers RPL Owner to block the RPL link and indicate the Blocked RPL link the ring in R-APS message, which when received by the nodes at the recovered link cause them to unblock that link and restore connectivity (again all nodes in the ring perform FDB Flush and MAC learning takes place). The ring is back in the normal (or idle) state.
Within each path, Y.1731 Maintenance Entity Group (MEG) Endpoints (MEPs) are used to exchange R-APS specific information (specifically to co-ordinate switchovers) as well as optionally fast Continuity Check Messages (CCM) providing an inherent fault detection mechanism as part of the protocol. Failure detection of a ring path by one of the mechanisms triggers to activate the protection links. Upon failure, re-convergence times are a dependent on the failure detection mechanisms. In the case of Y.1731, the CCM transmit interval determines the response time. The 7210 SAS device supports 100ms (millisecond) message timers that allows for quicker restoration times. Alternatively, 802.3ah (Ethernet in the First Mile) or simple Loss of Signal can act as a trigger for a protection switch where appropriate. In case of direct connectivity between the nodes, there is no need to use Ethernet CC messaging for liveliness detection.
Revertive and non-revertive behaviors are supported. The Ring protection link (RPL) is configured and Eth-rings can be configured to revert to the RPL upon recovery.
G.8032 supports multiple data channels (VIDs) or instances per ring control instance (R-APS tag). G.8032 also supports multiple control instances such that each instance can support RPLs on different links providing for a load balancing capability however after services have been assigned to one instance the rest of the services that need to be interconnected to those services must be on the same instance. That is each data instance is a separate data VLAN on the same physical topology. When there is any one link failure or any one node failure in the ring, G.8032 protocols are capable of restoring traffic between all remaining nodes in these data instances.
Ethernet R-APS can be configured on any port configured for access mode using dot1q, q-in-q encapsulation enabling support for Ethernet R-APS protected services on the service edge toward the customer site, or within the Ethernet backbone. ELINE and ELAN services can be afforded Ethernet R-APS protection and, although the Ethernet Ring providing the protection uses a ring for protection the services are configured independent of the Ring properties. The intention of this is to cause minimum disruption to the service during Ethernet R-APS failure detection and recovery.
In the 7210 SAS implementation, the Ethernet Ring is built from a VPLS service on each node with VPLS SAPs that provides Ring path with SAPs. As a result, most of the VPLS SAP features are available on Ethernet rings if desired. This results in a fairly feature rich ring service.
The control tag defined under each Eth-ring is used for encapsulating and forwarding the CCMs and the G.8032 messages used for the protection function. If a failure of a link or node affects an active Ethernet ring segment, the services will fail to receive the CC messages exchanged on that segment or will receive a fault indication from the Link Layer OAM module.
For fault detection using CCMs three CC messages plus a configurable hold-off timer must be missed for a fault to be declared on the associated path. The latter mechanism is required to accommodate the existence of additional, 50 ms resiliency mechanism in the optical layer. After it receives the fault indication, the protection module will declare the associated ring link down and the G.8032 state machine will send the appropriate messages to open the RPL and flush the learned addresses.
Flushing is triggered by the G.8032 state machine and the 7210 SAS implementation allows flooding of traffic during the flushing interval to expedite traffic recovery.
Figure 9 shows a resilient Ring Service example, in which a PBB ring (solid line) using VID 500 carries 2 service VLANs on I-SID 1000 and 1001 for Service VIDs (Dot1q 100 and QinQ 400.1 respectively). The RPL for the PBB ring is between A and B where B is the RPL owner. Figure 9 also shows a QinQ service on the (dotted line) ring that uses Dot1q VID 600 for the ring to connect service VLAN 100.50. The two rings have RPLs on different nodes, which allows a form of load balancing. The example demonstrates that service and ring encapsulation can be mixed in various combinations. Also, note that neither of the rings is a closed loop. A ring can restore connectivity when any one node or link fails to all remaining nodes within the 50ms transfer time (signaling time after detection).
Figure 9: 0-3 Resilient Ring Service Example
Sample Configuration:
2.4.5.2. Ethernet Ring Sub-Rings
Ethernet Sub-Rings offer a dual redundant way to interconnect rings. The 7210 SAS supports Sub-Rings connected to major rings and a sub-ring connected to a VPLS (LDP based) for access rings support in VPLS networks.
Figure 10 shows a Major ring and Sub Ring scenario. In this scenario, any link can fail in either ring (ERP1 or ERP2) and each ring is protected. Also, the sub ring (ERP2) relies on the major Ring (ERP1) as part of its protection for the traffic from C and D. The nodes C and D are configured as inter connection nodes.
Figure 10: 0-4 G.8032 Sub-Ring
Sub-Rings and Major Rings run similar state machines for the ring logic, however there are some differences. When Sub-Rings protect a link, the flush messages are propagated to the major ring. (A special configuration allows control of this option on the 7210 SAS.) When major rings change topology, the flush is propagated around the major ring and does not continue to any sub-rings. The reason for this is that Major Rings are completely connected but Sub-Rings are dependent on another ring or network for full connectivity. The topology changes need to be propagated to the other ring or network usually. Sub-Rings offer the same capabilities as major rings in terms of control and data so that all link resource may be utilized.
2.4.5.2.1. Virtual and Non-Virtual Channel
The following is a sample Sub-Ring using virtual-link configuration output on Node C, interconnecting node.
2.4.5.2.2. Ethernet Ring Sub Ring using non-virtual-link
Figure 11 shows an Ethernet sub-ring that uses a non-virtual link.
Figure 11: 0-6 Sub-Ring Homed to VPLS
| Note: In this solution the 7210 SAS nodes can only be the ring nodes. They cannot be used as the interconnection PE nodes. |
The following is a sample of Sub-Ring using non-virtual-link configuration output on PE1, interconnecting node.
All the Sub Ring nodes part of Sub Ring with non-virtual-link should be configured with “sub-ring non-virtual-link” option, as shown in the following sample configuration.
The following is a sample of a Sub-Ring using non-virtual-link configuration output homed to a major ring.
2.4.5.2.3. Lag Support
The 7210 SAS does not support G.8032 Ethernet rings on LAGs.
2.4.5.3. OAM Considerations
Ethernet CFM can be enabled on each individual path under an Ethernet ring. Only down MEPs can be configured on each of them and CCM sessions can be enabled to monitor the liveliness of the path using interval of 100 msec. Different CCM intervals can be supported on the path a and path b in an Ethernet ring. CFM is optional if hardware supports Loss of Signal for example.
UP MEPs on service SAPs which multicast into the service and monitor the active path may be used to monitor services.
2.4.5.4. QoS Considerations
When Ethernet ring is configured on two ports located on different IOMs, the SAP queues and virtual schedulers will be created with the actual parameters on each IOM.
Ethernet ring CC messages transmitted over the SAP queues using the default egress QoS policy will use NC (network class) as a forwarding class. If user traffic is assigned to the NC forwarding class, it will compete for the same bandwidth resources with the Ethernet CCMs. As CCM loss could lead to unnecessary switching of the Ethernet ring, congestion of the queues associated with the NC traffic should be avoided. The operator must configure different QoS Policies to avoid congestion for the CCM forwarding class by controlling the amount of traffic assigned into the corresponding queue.
Details of the Ethernet ring applicability in the services solution can be found in the respective Layer 2 sections of the 7210 SAS-M, T, Mxp, Sx, S Services Guide.
2.4.5.5. Support Service and Solution Combinations
The Ethernet rings are supported Layer 2 service. The following considerations apply.
- Only ports in access mode can be configured as Ethernet-ring paths.
- Dot1q and QinQ ports are supported as Ethernet-ring path members.
- A mix of regular and multiple Ethernet-ring SAPs and PWs can be configured in the same services.
2.4.5.6. Configuration Guidelines for G.8032
The configuration guidelines for G.8032 are the following.
- For 7210 SAS-M devices in network mode, use the config system resource-profile g8032-fast-flood-enable command to improve service fail-over time because of failures in the ring path. When fast-flood is enabled on failure detection in one of the paths of the Ethernet ring, along with MAC flush the system floods the traffic onto the available path. The resources needed for this functionality are shared with filters and affect filter scaling. Refer to the g8032-fast-flood-enable command in the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information.
- For 7210 SAS-T devices in network mode, users must enable the fast-flood feature and allocate the resources from the ingress-internal-tcam pool using the config system resource-profile g8032-fast-flood-enable command.
- For 7210 SAS-T devices in access-uplink mode, users do not need to enable the fast-flood feature or allocate the resources from the ingress-internal-tcam pool using the config system resource-profile g8032-fast-flood-enable command, because the resources are automatically allocated by the software.
- For 7210 SAS-Mxp devices in network mode, the fast-flood feature is enabled by default to improve the service fail-over time caused by failures in the ring path. If a failure is detected in one of the paths of the Ethernet ring, along with MAC flush, the system also floods the traffic to the available path. No explicit user configuration is required to facilitate this, and resource allocation from the ingress-internal-tcam pool is not needed.
- For 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, no explicit user configuration is needed to enable G.8032 fast-flood, and resources do not need to be allocated from the ingress-internal-tcam pool.
- Service-level MEPs are not available on SAPs tied to an Ethernet-ring instance on a port.
- G.8032 instances cannot be configured over a LAG.
- G.8032 version 2 is the supported version, by default. Use the config eth-ring compatible-version command to change the G.8032 version to 1, if required. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide for more information.
2.5. Service Creation Process Overview
Figure 12 shows the overall process to provision core and subscriber services.
Figure 12: Service Creation and Implementation Flow
2.6. Deploying and Provisioning Services
The service model provides a logical and uniform way of constructing connectivity services. The basic steps for deploying and provisioning services can be broken down into three phases.
2.6.1. Phase 1: Core Network Construction
Before the services are provisioned, the following tasks should be completed:
- build the IP or IP/MPLS core network
- configure routing protocols
- configure MPLS LSPs (if MPLS is used)
2.6.2. Phase 2: Service Administration
Perform preliminary policy configurations to control traffic flow, operator access, and to manage fault conditions and alarm messages, the following tasks should be completed:
- Configure group and user access privileges.
- Build templates for QoS, filter and/or accounting policies needed to support the core services.
2.6.3. Phase 3: Service Provisioning
- Provision customer account information.
- If necessary, build any customer-specific QoS, filter or accounting policies.
- Provision the customer services on the service edge routers by defining SAPs, binding policies to the SAPs.
2.7. Configuration Notes
This section describes service configuration caveats.
2.7.1. General
Service provisioning tasks can be logically separated into two main functional areas, core tasks and subscriber tasks and are typically performed before provisioning a subscriber service.
Core tasks include the following:
- Create customer accounts
- Create template QoS, filter, scheduler, and accounting policies
- Create SDPs (Not applicable for devices configured in Access Uplink mode)
Subscriber services tasks include the following:
- Create Epipe and VPLS services.
- Create a VPRN service (Supported only when operating in Network mode)
- Bind SDPs (Not applicable for 7210 SAS devices configured in Access Uplink mode)
- Configure interfaces (where required) and SAPs
- Create exclusive QoS and filter policies
To send and receive inband management traffic (for 7210 SAS configured in access uplink mode), create an IES service.