2.1.1. Service Types

The 7210 SAS-R6 and 7210 SAS-R12 provide the following types of subscriber services, which are described in more detail in the referenced chapters:

2.1.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, 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, and their functions, are:

2.3.1. Customers

The terms “customer” and “subscriber” 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.3.2. SAPs

Each subscriber service type is configured with at least one SAP. A SAP identifies the customer interface point for a service on a 7210 SAS router (). 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 (refer to 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:

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.

The Figure 2 shows SAPs 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:  SAPs for 7210 SAS Configured in Network Mode 

2.3.2.2. Ethernet Encapsulations

The following lists encapsulation service options on Ethernet ports:

1. 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).
2. dot1q
   Supports multiple services for one customer or services for multiple customers (Figure 3). 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.
3. 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. The 7210 SAS-R6, and 7210 SAS-R12 support QinQ encapsulation for access ports in network mode.

Figure 3:  Multiple SAPs on a Single Port 

Figure 3 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.

2.3.3. QinQ SAP Configuration Restrictions for 7210 SAS in Network Mode Only

The following are the QinQ access SAP configuration guidelines for 7210 SAS in network mode only.

A 0.* QinQ SAP configured in the service will only accept untagged or priority-tagged packets, regardless of whether a QinQ SAP is configured in the service.

Note: The 7210 SAS supports a mechanism to transport QinQ packets in an Epipe with two or more tags, with some restrictions. For more information, see Ethernet Pipe (Epipe) Services.

2.3.4. SDPs

An SDP provides a logical way to direct traffic from one router to another through a unidirectional (one-way) service tunnel. The SDP terminates at the far-end router, which directs packets to the correct service egress SAPs on that router. 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 that binds the service to the service tunnel.

An SDP has the following characteristics:

An SDP from the local router to a far-end router requires a return path SDP from the far-end router 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.3.4.1. SDP Binding

To configure a distributed service from ALA-A to ALA-B, the 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, the SDP ID (5) must be specified.

Figure 4 shows MPLS service distribution point pointing from ALA-A to ALA-B.

Figure 4:  MPLS SDP Pointing From ALA-A to ALA-B 

2.3.4.6. Mixed-LSP Mode of Operation

The mixed-LSP mode of operation 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 specific time, the service manager programs only one type of LSP in the line card, which will activate it to forward service packets according to the following priority order:

1. RSVP LSP type: one RSVP LSP can be configured per SDP. This is the highest priority LSP type.
2. LDP LSP type: one LDP FEC will be used per SDP. The 7210 SAS does not support LDP ECMP.
3. 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 LSP type becomes available, the service manager reverts back 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, then the SDP reverts to the highest priority LSP type only if the currently active LSP failed.

Note: LDP uses a tunnel down damp timer which is set to three seconds by default. When the LDP LSP fails, the SDP will revert to the RSVP LSP type after the expiry of this timer. For an immediate switchover this timer must be set to zero. Use the configure>router>ldp>tunnel-down-damp-time command. For more information, refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S MPLS Guide.

If the value of the revert-time timer is changed, it will take effect only at the next use of the timer. Any timer which is outstanding at the time of the change will be restarted with the new value.

In the case of the LDP/BGP SDP, the service manager will prefer the LDP LSP type over the BGP LSP type. The service manager will reprogram the line card with the BGP LSP, if available; otherwise, it brings down the SDP operationally.

Note: The following are differences in behavior of the LDP/BGP SDP compared to that of 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 specific time. The impact of this is that the tunnel table needs to be reprogrammed each time a route is deactivated and the other is activated. The SDP revert-time cannot be used, because there is no situation where both LSP types are active for the same /32 prefix.

2.3.5. SAP and Service Scaling with High SAP Scale Mode

In Layer 2 access networks that are used to backhaul service traffic from business services, mobile backhaul, and residential services, the 7210 SAS-R6 and 7210 SAS-R12 act as a Layer 2 carrier Ethernet switching platform with VLAN-based Layer 2 uplinks. To perform this role, the 7210 SAS-R6 and 7210 SAS-R12 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-R6 and 7210 SAS-R12 use the SAP scale mode and port-based access ingress policies.

Figure 5 shows the use of Layer 2 uplinks in a Layer 2 access network.

Figure 5:  Using Layer 2 Uplinks in a Layer 2 Network 

The SAP scale mode is configured using the configure>system>global-res-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 tasks.

In 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 R-VPLS services remain unchanged.

QoS policies support port-based access ingress policies on access ports to facilitate the use of access ports as Layer 2 uplinks. With the use of ports as Layer 2 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 Layer 2 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:

The following SAP configuration restrictions apply to the high SAP scale mode; see SAPs for additional SAP configuration guidelines.

2.3.6. Overview of G.8032 Operation

R-APS messages that carry the G.8032 protocol are sent on a 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 R-APS 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 except 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 from other ring links. Revertive mode provides predictability, particularly when there are multiple ring instances, and the operator can control which links are blocked on the different instances. Each time that 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 6 shows this initial operational state.

Figure 6:  G.8032 Ring in the Initial State 

When a ring failure occurs, a node detecting the failure (enabled by Y.1731 OAM CC monitoring) sends 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 an 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 7 shows the failed link scenario.

Figure 7:  0 to 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 causes the RPL owner to block the RPL link and indicate the blocked RPL link to the ring in R-APS message, when received by the nodes at the recovered link, they unblock that link and restore connectivity (again all nodes in the ring perform an 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 coordinate switchovers) as well as optionally fast Continuity Check Messages (CCMs), providing an inherent failure detection mechanism as part of the protocol. Failure detection of a ring path by one of the mechanisms activates the protection links. Upon failure, reconvergence times are 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 100 ms message timers that allow for quicker restoration times. Alternatively, 802.3ah (Ethernet in the First Mile) or LOS can trigger a protection switch where appropriate. In the 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 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, when services have been assigned to one instance, the rest of the services that need to be interconnected with 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.

There is no limit on the number of control channels on a port.

Ethernet R-APS can be configured on any port configured for access mode using dot1q, QinQ 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 provided 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 intent 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 needed. 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 failure 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 an 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.

2.3.7. 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 ring support in VPLS networks. Figure 8 shows a major ring and sub-ring scenario, and Figure 9 shows a G.8032 sub-ring. 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 interconnection nodes.

Figure 8:  Major Ring and Sub-ring Scenario 

Figure 9:  0 to 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 resources may be used.

2.3.7.2. Ethernet Ring Sub-ring Using Non-virtual Link

Figure 10 shows 0 to 6 homed to VPLS.

Figure 10:  0 to 6 Sub-ring Homed to VPLS 

Note: In this solution, the 7210 SAS nodes can only be the ring nodes. It cannot be used as the interconnection PE nodes.

The following is a sample sub-ring using non-virtual link configuration output on PE1, interconnecting node.

eth-ring 1

      description "Ethernet Ring 1"

      guard-time 20

      no revert-time

      rpl-node nbr

      sub-ring non-virtual-link

          interconnect vpls // VPLS is interconnection type

              propagate-topology-change 

          exit

      exit

      path a 1/1/3 raps-tag 1.1

          description "Ethernet Ring : 1 Path on LAG"

          eth-cfm

          mep 8 domain 1 association 8

               ccm-enable

               control-mep

               no shutdown

            exit

        exit

        no shutdown

    exit

    no shutdown

exit

All the sub ring nodes part of a sub-ring with non-virtual link should be configured with the “sub-ring non-virtual-link” option.

eth-ring 1

        sub-ring non-virtual-link

        exit

        path a 1/1/1 raps-tag 1.1

            eth-cfm

                mep 5 domain 1 association 4

                    ccm-enable

                    control-mep

                    no shutdown

                exit

            exit                      

            no shutdown

        exit

        path b 1/1/2 raps-tag 1.1

            eth-cfm

                mep 6 domain 1 association 3

                    ccm-enable

                    control-mep

                    no shutdown

                exit

            exit

            no shutdown

        exit

        no shutdown

    exit

# Control Channel for Sub-Ring using non-virtual-link on interconnecting node: 

vpls 1 customer 1 create

      description "Ring 1 Control termination"

      stp shutdown

      sap 1/1/3:1.1 eth-ring 1 create //path a control

          stp shutdown

      exit

      no shutdown

  exit

# Configuration for the ring data into the VPLS Service

 

  vpls 5 customer 1 create

      description "VPLS Service at PE1"

      stp

          no shutdown

      exit

      sap 1/1/3:2.2 eth-ring 1 create

          stp shutdown

      exit

      sap 1/1/5:1 create

      exit

      mesh-sdp 5001:5 create //sample LDP MPLS LSPs

      exit

      mesh-sdp 5005:5 create

      exit

      mesh-sdp 5006:5 create

      exit

          

      no shutdown

  exit

# Control Channel for Sub-Ring using non-virtual-link on sub-Ring nodes:

vpls 1 customer 1 create

            stp

                shutdown

            exit

            sap 1/1/1:1.1 eth-ring 1 create

                stp

                    shutdown

                exit

            exit

            sap 1/1/2:1.1 eth-ring 1 create

                stp

                    shutdown

                exit

            exit                      

            no shutdown

        exit

 

The following is a sample sub-ring using non-virtual link configuration output homed to a major ring.

eth-ring 1

      description "Ethernet Ring 1"

      guard-time 20

      no revert-time

      rpl-node nbr

      sub-ring non-virtual-link

interconnect ring-id <major ring index>

              propagate-topology-change 

          exit

      exit

      path a 1/1/3 raps-tag 1.1

          description "Ethernet Ring : 1 Path on LAG"

          eth-cfm

          mep 8 domain 1 association 8

               ccm-enable

               control-mep

               no shutdown

            exit

        exit

        no shutdown

    exit

    no shutdown

exit

2.3.8. Support for Hardware-based 100ms CCM Timers for G.8032 MEPs

On the 7210 SAS-R6 and 7210 SAS-R12, the user must reserve a VLAN-ID for use with only G.8032 MEPs which uses the hardware for CCM processing. No data services or control SAPs can use this VLAN-ID. The CLI command description used to reserve the VLAN-ID is available in the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide.

When using hardware CCMs, a limited amount of control instances is supported per port. Multiple data services/instances can be associated with each of these control instances.

The following is a sample configuration output with the control-sap-tag command.

2.3.9. 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 an interval of 100 ms. Different CCM intervals can be supported on path A and path B in an Ethernet ring. CFM is optional if hardware supports LOS, for example.

Service Down MEPs cannot be configured on the same port as the G.8032 ring ports.

2.3.10. 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. Because 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.

More information about the Ethernet ring applicability in the services solution, refer to the respective Layer 2 sections of the 7210 SAS-R6, R12 Services Guide.

2.3.11. Support Service and Solution Combinations

Ethernet rings are a supported Layer 2 service. The following considerations apply:

2.3.12. Configuration Guidelines for G.8032

The following are the configuration guidelines for G.8032:

2.5.1. Phase 1: Core Network Construction

Before the services are provisioned, the following tasks should be completed:

2.5.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:

2.5.3. Phase 3: Service Provisioning

For service provisioning, the following tasks should be completed:

2.6.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:

Subscriber services tasks include the following: