2. Services Overview

This chapter provides an overview of the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C subscriber services, service model, and service entities. Additional information about the individual subscriber services supported on different 7210 SAS platforms and their configuration options is in subsequent chapters.

2.1. 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.

On the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T platforms, services can provide Layer 2/bridged service between a service access point (SAP) and another service access point (a SAP is where traffic enters and exits the service) on the same (local) router. It cannot support distributed services using MPLS uplinks.

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C platforms, services can provide Layer 2/bridged service or Layer 3/IP routed connectivity between a service access point (SAP) on one router and another SAP (which is where traffic enters and exits the service) on the same (local) router or another router (distributed). The use of either MPLS uplinks or Ethernet uplinks is supported.

The7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support both local and distributed service. A distributed service spans more than one router. Distributed services use service distribution points (SDPs) to direct traffic through a service tunnel to another Nokia router. 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, the far-end router is not able to participate in the service (there is no service without associating an SDP with the service).

2.1.1. Service Types on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

The 7210 SAS-D,7210 SAS-Dxp, and 7210 SAS-K 2F1C2T offer the following types of subscriber services, described in more detail in the referenced chapters:

  1. Virtual Leased Line (VLL) services:
    1. Ethernet pipe (Epipe)
      A Layer 2 point-to-point VLL service for Ethernet frames. See Epipe for more information about Epipe.
  2. Virtual Private LAN Service (VPLS) — A Layer 2 multipoint-to-multipoint VPN bridging service or VPN (using QinQ uplinks). See Virtual Private LAN Service for more information about VPLS.

2.1.2. Service Types on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C offer the following types of subscriber services, described in more detail in the referenced chapters:

  1. Virtual Leased Line (VLL) services
    1. Ethernet pipe (Epipe) — A Layer 2 point-to-point VLL service for Ethernet frames. See Epipe for more information.
  2. Virtual Private LAN Service (VPLS)
    VPLS is a Layer 2 multipoint-to-multipoint VPN bridging service or VPN (using QinQ uplinks). See Virtual Private LAN Service for more information.
  3. Routed VPLS Service (R-VPLS)
    An R-VPLS integrates routing and bridging into a single service. It provides the capability to provide Layer 2 multipoint-to-multipoint services locally on the node, typically using an IP interface for uplink connectivity. See Virtual Private LAN Service for more information.
  4. Internet Enhanced Services (IES)
    IES is a direct Internet access service where the customer is assigned an IP interface for Internet connectivity. See the Internet Enhanced Service on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T for more information about IES.
  5. Virtual Private Routed Network (VPRN)
    VPRN is a Layer 3 IP multipoint-to-multipoint VPN service as defined in RFC 2547bis. See Virtual Private Network Service on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C for more information.

2.1.3. Service Policies on 7210 SAS-D and 7210 SAS-Dxp

Common to connectivity services on 7210 SAS-D and 7210 SAS-Dxp platforms are policies 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 common to all 7210 SAS-series connectivity services are:

  1. SAP Quality of Service (QoS) policies allow different classes of traffic within a service at SAP ingress. Access egress QoS policies allow differential treatment of various traffic classes within a service (SAPs) which exists in an egress port.
    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, and so on) 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 QoS policy can be associated with a SAP. A single access egress QoS policy can be associated with a port.
  2. 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.
  3. 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.
  4. 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 that enables network operators to accurately measure network usage and bill each customer for each individual service using any of several billing models.

2.2. Service Policies on 77210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

Common to connectivity services on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4Tand 7210 SAS-K 3SFP+ 8C, are policies 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 service enhancements. The types of policies common to all 7210 SAS connectivity services, and their functions, are:

  1. SAP Quality of Service (QoS) policies allow different classes of traffic within a service at SAP ingress and at SAP egress.
    QoS ingress and egress policies determine the QoS characteristics for a SAP. A QoS ingress and egress policies applied to a SAP specifies the number of queue, queue characteristics (such as forwarding class, committed, and peak information rates, and so on) and the mapping of traffic to a forwarding class. 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.
  2. Filter policies allow selective blocking of traffic matching criteria from ingressing and 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 with 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.
  3. 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 that enables network operators to accurately measure network usage and bill each customer for each individual service, using any of several billing models.

2.3. Nokia Service Model on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

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 generic router encapsulation MPLS label-switched paths (LSPs). The 7210 SAS-D, 7210 SAS-Dxp, and 77210 SAS-K 2F1C2T support only QinQ and dot1q Layer 2 uplinks, which are used to transport the services to the provider edge in a hierarchal configuration. The platforms do not support transport tunnels that use MPLS LSPs.

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 the following.

  1. Many services can be bound to a single customer.
  2. 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, and accounting/billing to the appropriate entity.

2.4. Nokia Service Model on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 generic router encapsulation MPLS label-switched paths (LSPs). The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support transport tunnels that use MPLS LSPs or QinQ/dot1q Layer 2 uplinks. These tunnels are used to transport the services to the provider edge in a hierarchical configuration.

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 the following.

  1. Many services can be bound to a single customer.
  2. Many services can be bound to a single tunnel.
  3. Tunnel configurations are independent of the services they carry.
  4. Changes are made to a single logical entity rather than multiple ports on multiple devices. It is easier to change one tunnel rather than several services.
  5. The operational integrity of a logical entity (such as a service tunnel and service endpoints) can be verified rather than dozens of individual services improving management scaling and performance.
  6. On 7210 SAS platforms, a failure in the network core can be correlated to specific subscribers and services.
  7. 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.5. Service Entities on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

The basic logical entities in the service model used to construct a service are:

  1. Customers
  2. SAPs on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

2.6. Service Entities on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

The basic logical entities in the service model used to construct a service are:

  1. Customers
  2. SAPs on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T
  3. SAPs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
  4. SAP Encapsulation Types and Identifiers
  5. SDPs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C
  6. G.8032/Ethernet Ring Protection Switching
  7. Layer 2 Control Processing
  8. Service Creation Process Overview

2.6.1. Customers

The terms “customer” and “subscriber” are used synonymously. The most basic required entity is the customer ID value, 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.7. SAPs on 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T

Each subscriber service type is configured with at least one SAP. Figure 1 shows how 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-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide).

A SAP is a local entity to the router and is uniquely identified by:

  1. physical Ethernet port
  2. encapsulation type
  3. 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” or “access uplink” in the physical port configuration. SAPs can be created on ports designated as core facing “access uplink” ports. These ports have a different set of features enabled in software.

Figure 1:  Multiple SAPs in a Service Using QinQ Uplinks in 7210 SAS Configured in Access-uplink Mode 

Figure 1 shows SAPs 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 Layer 2 uplinks (also known as access-uplink mode platforms).

2.8. SAPs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

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 (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 (refer to the Cards, MDAs, and Ports sections of the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide).

A SAP is a local entity to the router and is uniquely identified by:

  1. physical Ethernet port
  2. encapsulation type
  3. 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:  Multiple SAPs for 7210 SAS Configured with MPLS Uplinks 

Figure 2 shows SAPs used for customer service delivery, with SDP used for service transport on 7210 SAS devices that support MPLS uplinks.

SAPs can be created on ports designated as core facing “access uplink” ports when using QinQ uplinks. Access-uplink ports have a different set of features enabled in software.

Figure 3 shows SAPs used for customer service delivery with access-uplink SAPs (also known as QinQ SAPs) used for service transport on 7210 SAS devices when using Layer 2 uplinks.

Figure 3:  Multiple SAPs in a Service Using QinQ Uplinks in 7210 SAS Configured in Access-uplink Mode 

2.9. 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.9.1. Ethernet Encapsulations Supported on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

The following lists encapsulation service options on Ethernet access 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 4). For example, the port is connected to a customer who needs multiple services. The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header.
  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 following lists encapsulation service options on Ethernet access-uplink ports:

  1. 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:  Multiple SAPs on a Single Port 

2.9.2. Services and SAP Encapsulations

Table 5 lists the service and SAP encapsulation information for Ethernet ports.

Table 5:  Service and SAP Encapsulation for Access Ports 

Port Type

Encapsulation

7210 SAS Platforms Support

Ethernet

null

All

Ethernet

Dot1q

All

Ethernet

QinQ

7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

Table 6 lists the service and SAP encapsulation information for Ethernet access-uplink ports.

Table 6:  Port Type and Encapsulation for Access-uplink Ports 

Port Type

Encapsulation

7210 Platforms

Ethernet access-uplink

QinQ

All

2.9.3. Default SAPs on a Dot1q Port

This feature provides 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.

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 that is reserved to manage the CPE. The service SAP covers all other VLANs and behaves as a SAP on a null-encapsulated port.

There are a few constraints related to the use of a default SAP on a dot1q-encapsulated port:

  1. This type of SAP is supported only on VPLS and Epipe services, and cannot be created in IES services because it cannot preserve VLAN tag markings.
  2. 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.
  3. IGMP snooping is not supported on a default SAP. This would require remembering VLAN tags per hosts. By not allowing IGMP snooping on this SAP, all IGMP packets will be transparently forwarded.

2.9.4. Default SAPs on a QinQ Port

Default QinQ SAPs (notation *.*) are used in ring ports to avoid the need to configure services on all the intermediate nodes in the ring that are transiting the service. Default QinQ SAPs match all VLAN-tagged traffic that 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 only allowed on access-uplink ports and access ports. A default QinQ SAP can coexist with a 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. 7210 SAS-K, accepts untagged and tagged packets on a default QinQ SAP.

When an Epipe service with default QinQ SAPs on the ring ports is used for transit traffic in a ring deployment, no protection mechanism (for example, STP or G.8032) is supported for default QinQ SAPs. The upstream or head-end node on which the service originates must ensure that 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:

A G.8032 control instance cannot use default QinQ SAPs.

The 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 the following is true.

  1. On the 7210 SAS-D and 7210 SAS-Dxp, a default QinQ SAP accepts only tagged packets. Untagged packets or priority-tagged packets are not accepted on default QinQ SAPs.
  2. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, a default QinQ SAP accepts both untagged and tagged packets.
  3. On the 7210 SAS-D and 7210 SAS-Dxp, 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”).
  4. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, default QinQ SAP is available for use only in an Epipe and a VPLS service created with svc-sap-type parameter set to “any”. 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 “any”).
  5. MAC learning and aging is available for use in a VPLS service.
  6. Per-SAP MAC limit is available for use in a VPLS service.
  7. Mac-move detection and Mac-pinning is available for use in a VPLS service.
  8. Discard-unknown and discard-unknown-source is available for use in a VPLS service.
  9. Ethernet Connectivity Fault Management (ETH-CFM) and Y.1731 are not available for use.
  10. STP (and all its different flavors) cannot be enabled in the service with default QinQ SAPs.
  11. M-VPLS with xSTP can be used for loop prevention. The default QinQ SAPs inherit the state from the associated M-VPLS instance.
  12. A G.8032 control instance cannot be configured in a service with a default QinQ SAP.
  13. 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 instance 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.
  14. IGMP snooping is not available for use.
  15. L2PT and BPDU translation is not available for use.
  16. On the 7210 SAS-D and 7210 SAS-Dxp, IP interface in a VPLS service is not supported in a service priority-taggedpriority-taggedusing this SAP. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, IP interface in a VPLS service is not supported (irrespective of SAP encapsulations).

For default QinQ SAPs created on an access-uplink port, the following is true.

  1. Ingress QoS policies applied on an access-uplink port is available for classification and policing on ingress.
  2. Egress QoS policy applied on an access-uplink port is available for egress queue shaping, scheduling, and marking.
  3. SAP ingress ACLs are available for use.
  4. SAP egress ACLs are not available for use.
  5. 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, the following is true.

  1. A SAP ingress QoS policy is available for use.
  2. On the 7210 SAS-D and 7210 SAS-Dxp, an egress QoS policy applied on an access port is available for egress shaping, scheduling, and marking.
  3. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, an egress QoS policy applied on an access SAP is available for egress shaping, scheduling and marking.
  4. SAP ingress ACLs are available for use.
  5. SAP egress ACLs are not available for use.
  6. On the 7210 SAS-D and 7210 SAS-Dxp, SAP ingress meter counters, SAP ingress received count, and SAP egress forwarded counter are available for use (appropriate accounting records can be used).
  7. On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, SAP ingress queue counters, SAP ingress received count, and SAP egress forwarded counter are available for use (appropriate accounting records can be used).

2.9.4.1. Configuration Notes for Default QinQ SAPs for Transit Service in a Ring Deployment

  1. 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 that 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 M-VPLS 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.
  2. If a VPLS service is used with default QinQ SAPs on the ring ports for transit service in a ring deployment, either M-VPLS/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 services that are originating on different nodes in the ring and use the transit VPLS service are also protected. Epipe services that are originating on different nodes in the ring cannot use the transit VPLS service.
  3. When using VPLS service with default QinQ SAPs for transit service with either G.8032 or M-VPLS with xSTP configured for protection, load-balancing of the traffic based on the VLAN IDs is not possible. If load-balancing is needed, then it is better to use Epipe service with default QinQ SAPs as the transit service.

2.9.5. SAP Configuration Considerations Applicable for SAPs Configured on Access-uplink Ports

Note:

On the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the simultaneous configuration of access-uplink and network operating modes, without explicit BOF configuration, is supported. A mix of access-uplink and network ports can be simultaneously configured on these platforms.

When configuring a SAP, consider the following:

  1. 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 device.
  2. On the 7210 SAS-D and 7210 SAS-Dxp, a physical port can only have one SAP to be part of one service. Multiple SAPS can be defined over a physical port but each of these SAPs must belong to a different service.
  3. On the 77210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, multiple SAPs configured on the same port can be part of the same service.
  4. The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support the use of a Q1.0 SAP. This SAP matches packets received on a port with the outermost tag being Q1 and the inner tag being absent (that is, no tag) or the inner tag is a priority tag. It does not accept packets with any other VLAN tag value as the inner tag.
  5. There are no default SAPs configured on the node. All SAPs in subscriber services must be created.
  6. The default administrative state for a SAP at creation time is administratively enabled.
  7. When a SAP is deleted, all configuration parameters for the SAP will also be deleted.
  8. An access SAP is owned by and associated with the service in which it is created in each router.
  9. 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.
    Note:

    Some exceptions to this are dot1q range SAPs and dot1q preserve SAPs configured on a port with dot1q encapsulation.

  10. If a port is administratively shut down, all SAPs on that port are operationally out of service.
  11. A SAP cannot be deleted until it has been administratively disabled (shut down).
  12. Each SAP can have one each of the following policies assigned:
    1. ingress filter policy
    2. egress filter policy
    3. ingress QoS policy
    4. accounting policy
    5. egress QoS policy on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C
  13. An ingress QoS policy and accounting policy is assigned per access-uplink port and cannot be assigned per access-uplink SAP. That is, all access-uplink SAPs on a specific port share the QoS policy.
  14. Ingress filter policy and egress filter policy is available per access-uplink SAP.
  15. The svc-sap-type parameter value determines the type of SAPs provisioned in a service.
    1. provides details of SAP and service combinations allowed in 7210 SAS-D and 7210 SAS-Dxp devices
    2. provides details of SAP and service combinations allowed in 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C devices
  16. If 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 the access port is not stripped, when svc-sap-type is set to dot1q-preserve.
  17. For dot1q range SAP, the outermost VLAN tag is compared against the range of VLAN IDs configured and mapped to the SAP if there is a match. The outermost tag is not stripped on SAP ingress and is forwarded through the other service endpoint.
  18. L2PT cannot be configured for use on all the configured SAPs simultaneously. The number of SAPs that can use this simultaneously is less than the maximum number of SAPs supported by the node.

2.9.5.1. Configuration Guidelines for 7210 SAS-D and 7210 SAS-Dxp

Consider the following guidelines.

  1. Ensure that egress SAP counters are enabled before associating accounting records that count egress forwarded packets.
  2. Before modifying the counter, disable the account log generation and run the no collect-stats command.
  3. Egress SAP statistics are not available on any of the SAPs of a port, on which a dot1q SAP and dot1q default SAP configuration are present at the same time. This limitation also applies for egress ACLs. That is, egress ACLs are not supported on either dot1q SAPs or dot1q default SAPs when both these SAPs are configured on a port simultaneously.
  4. Egress SAP statistics cannot be configured for use simultaneously on all the configured SAPs. The number of SAPs that can use this feature simultaneously is less than the maximum number of SAPs supported by the node.
  5. Service MTU is not supported on the 7210 SAS-D.
  6. QinQ access SAPs of the type Q1.0 are not supported.

Table 7 lists the SAPs allowed with different values for the svc-sap-type on 7210 SAS-D and 7210 SAS-Dxp.

Table 7:  SAP and Service Combinations for 7210 SAS-D and 7210 SAS-Dxp 

svc-sap-type

Access SAPs

Access-uplink SAPs

null-star

null SAP,

Dot1q default SAP

Q.* SAP,

0.* SAP

default QinQ SAP (*.* SAP)

Q.* SAP,

0.* SAP

default QinQ SAP (*.* SAP)

dot1q-preserve

Dot1q SAP (Dot1q VLAN tag not stripped on ingress),

Q1.Q2 SAP (Q2 tag VLAN must match the Dot1q SAP VLAN ID)

Q1.Q2 SAP (Q2 tag VLAN ID must match the Dot1q SAP VLAN ID)

any

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

  1. A dot1q default SAP cannot be configured when the svc-sap-type is set to any.
  2. 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 are dropped. Users can use the service with the svc-sap-type set to null-star, to process and forward packets with one or more tags (including priority tag) on a null SAP.
  3. 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 untagged packets, even if 0.* SAP is not configured for use on that port.
  4. The default QinQ SAPs are 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).
  5. In a VPLS service, the default QinQ SAP is available for use with any other SAP type configured in a service configured with the svc-sap-type parameter set to null-star.
  6. SAPs using connection profiles (to specify dot1q VLAN ranges) can be configured in a service only when the svc-sap-type is set to dot1q-range.
  7. When a service is configured to use svc-sap-type dot1q-range, the outermost V-LAN tag of the packets is not stripped when the packet is received on access port ingress. See Epipe for information about processing behavior for this type of service.
  8. Service MTU is not supported on 7210 SAS-D.
  9. The following counters are available on 7210 SAS-D and 7210 SAS-Dxp devices:
    1. ingress and egress counters per SAP
    2. ingress policer counters per SAP
    3. egress queue counters per access port
    4. ingress and egress counters per access-uplink port
  10. The number of counters available to count total received packets or octets on an access-uplink SAP (in a VPLS, VLL or IES service) ingress is limited; therefore a count of received packets or octets cannot be obtained for all the SAPs simultaneously. By default, these counts are not available.
  11. The config service epipe sap statistics ingress command is available to associate a counter with the SAP and obtain the counts.
  12. The number of counters available to count total forwarded packets or octets on an access SAP egress and access-uplink SAP egress is limited and therefore a count of received packets or octets cannot be obtained for all the SAPs simultaneously. By default, these counts are not available.
  13. The config service epipe sap statistics ingress forwarded-count command is available to associate a counter with the SAP and obtain the counts.

2.9.5.2. Configuration Guidelines for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C

  1. The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support the following types of SAPs:
    1. access SAPs
      null, dot1q (dot1q, dot1q default, dot1q range, dot1q explicit null), QinQ SAPs (Q1.Q2, Q1. *, Q1.0 QinQ default SAP (that is, *.* SAP), 0.*) are supported.
    2. access-uplink SAPs
      QinQ SAPs (various SAP types, such as Q1.Q2, QinQ default SAP (*.* SAP), 0.*, Q1.*, Q1.0) are supported.
  2. The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support Q1.0 SAP. This SAP accepts a packet with the outermost tag as Q1 or a packet with outermost tag as Q1 and the following inner tag is a priority tag. Unlike 7x50, it does not accept packets with two tags with the outermost tag being Q1 and the inner tag being any tag other than priority tag.
  3. The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C allow any port to be configured in either access-uplink mode or access mode. Additionally the ports can be in access-uplink mode or access mode or they can be mix of the ports using either modes. There is no limit to the number of access ports allowed to be configured. That is, all ports can be configured as access ports. The number of access-uplink ports depends on the number of QoS resources allocated per port. That is, not all the ports can be configured as access-uplink ports at a specific time.
  4. The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support service MTU.
    1. A received frame/packet length is checked against the configured service MTU after subtracting the length of the SAP encapsulation (including the Layer 2 header) from the received frame length. The packet is further processed in the context of the service, if the computed length is less than equal to the configured service MTU or the packet is dropped.
    2. The user must configure the correct service MTU across all the nodes, if support is available, through which the service is transported.
  5. The 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C support only the following svc-sap type parameters:
    1. ‘any’ – A service configured with this value for svc-sap-type allows for configuration of all combination of access SAPs and access-uplink SAPs in the same service, except for dot1q range SAPs. A packet that is received with tags more than the number of SAP tags to which it is mapped to, is forwarded transparently in the service (the processing behavior is similar to any other packet mapped to the SAP).
    2. ‘dot1q-range’ – A service configured with this value for svc-sap-type allows for configuration of dot1q range SAPs and Q1.* access-uplink SAP in the same service.

Table 8 lists the SAPs allowed on the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C with different values of svc-sap-type.

Table 8:  SAP and Service Combinations for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C 

svc-sap-type

Access SAPs

Access-uplink SAPs

any

null SAP,

Dot1q SAP,

Dot1q explicit null SAP

Dot1q default SAP

Q1.Q2 SAP,

Q.* SAP,

Q1.0 SAP,

0.* SAP

QinQ default SAP (*.* SAP)

Q1.Q2 SAP,

Q.* SAP,

Q1.0 SAP,

0.* SAP,

QinQ default SAP (*.* SAP)

dot1q-range

Dot1q SAP (Dot1q VLAN tag not stripped on ingress), Q1.* SAP

Q1.* SAP

2.10. SDPs on 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C

Note:

SDPs are only supported on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

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:

  1. An SDP is locally unique to a participating router. The same SDP ID can appear on other 7210 SAS-series routers.
  2. An SDP uses the system IP address to identify the far-end edge router.
  3. 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.
  4. All services mapped to an SDP use the same transport encapsulation type defined for the SDP.
  5. 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 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.10.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 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 5 shows MPLS service distribution pointing from ALA-A to ALA-B.

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

2.10.2. Spoke and Mesh SDPs

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 support 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.10.3. SDP Using BGP Route Tunnel

SDPs are 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 the 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). The BGP route tunnel method is excluded if multimode transport is enabled for an SDP.

For inter-AS far-end PE, the next-hop for the BGP route tunnel must be one of the local ASBRs. 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 a transport LSP to reach the BGP route tunnel next-hop.

Only BGP route labels can be used to transition from an 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 the 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. An LDP LSP must be preferred due to higher protocol priority. This leads to just one label, besides other labels in the stack to identify the VC/VPN at far-end PE nodes.

2.10.4. SDP Keepalives

SDP keepalives actively monitor the SDP operational state using periodic SDP ping echo request and echo reply messages. SDP ping is a part of the 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 SDP have the following configurable parameters:

  1. admin up/admin down state
  2. hello time
  3. message length
  4. max drop count
  5. hold down time

SDP keepalive echo request messages are only sent when the SDP is completely configured and administratively up and SDP keepalives are 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 operationally up state.

For information about configuring keepalive parameters, see Configuring an SDP.

2.10.5. SDP Administrative Groups

This feature provides the support of SDP administrative groups, referred to as SDP admin groups. SDP admin groups provide a way for services using a PW template to automatically include or exclude specific provisioned SDPs. SDPs sharing a specific characteristic or attribute can be made members of the same admin group.

The user first creates the admin groups used by SDPs on this node:

config>service>sdp-group>group-name group-name value group-value create

A maximum of 32 admin groups can be created. The no option is only allowed if the group-name is not referenced in a pw-template or SDP.

The group value ranges from zero (0) to 31. It is uniquely associated with the group name at creation time. If the user attempts to configure another group name for a group value that is already assigned to an existing group name, the SDP admin group creation is failed. The same happens if the user attempts to configure an SDP admin group with a new name but associates it to a group value already assigned to an existing group name.

Next, the user configures the SDP membership in admin groups:

config>service>sdp>sdp-group group-name

The user can enter a maximum of one (1) admin group name. The user can execute the command multiple times to add membership to more than one admin group. The admin group name must have been configured or the command is failed. Admin groups are supported on an SDP and of type MPLS (BGP/RSVP/LDP). They are also supported on an SDP with the mixed-lsp-mode option enabled.

The user then selects which admin groups to include or exclude in a specific PW template:

config>service>pw-template>sdp-include group-name

config>service>pw-template>sdp-exclude group-name

The admin group name must have been configured or the command is failed. The user can execute the command multiple times to include or exclude more than one admin group. The sdp-include and sdp-exclude commands can only be used with the use-provisioned-sdp option. If the same group name is included and excluded within the same PW template, only the exclude option will be enforced.

Any changes made to the admin group sdp-include and sdp-exclude constraints will only be reflected in existing spoke-SDPs after the following command has been executed:

tools>perform>service>eval-pw-template>allow-service-impact

When the service is bound to the PW template, the SDP selection rules will enforce the admin group constraints specified in the sdp-include and sdp-exclude commands.

config>service>vpls>bgp>pw-template-binding policy-id

config>service>epipe>spoke-sdp-fec>pw-template-bind policy-id

The group value is what is used to uniquely identify an SDP admin group throughout the network in the NSP NFM-P. The node will send both the group name and value to the NSM NFM-P or other SNMP device, at the creation of the SDP admin group. In all other operations in the node, such as adding an SDP to an admin group or including/excluding an SDP admin group in a service context, only the group name is sent to the NSP NFM-P or the SNMP device.

SDP admin groups can be enabled on all 7210 SAS services that make use of the PW template (that is, BGP-AD VPLS service).

2.10.6. Mixed-LSP Mode of Operation

The mixed-LSP 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, 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 can be used per SDP. The 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C support LDP ECMP.
  3. BGP LSP type
    One RFC 3107-labeled BGP prefix, which is programmed by the service manager, is used.

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-K 2F6C4T, K 3SFP+ 8C 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.

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

2.11. G.8032/Ethernet Ring Protection Switching

Note:

On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C, CCMs used for G.8032 Ethernet ring protection service are implemented in hardware.

Ethernet ring protection switching (Eth-ring) provides ITU-T G.8032 specification compliance to achieve resiliency for Ethernet Layer 2 networks.G.8032 Eth-ring is implemented 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, SAPs. The Eth-ring service 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 of G.8032 Eth-ring can be used for interconnecting access rings and to provide traffic engineered backbone 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.11.1. 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 or nodes 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:  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 cause them to 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.

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.

The following diagram shows an example G.8032 ring. The following 0 to 3 Ring Example shows a resilient ring service. In the ring example, a QinQ ring (solid line) using VID 500 carries two customer VLANs dot1q 100 and QinQ 400.1, respectively). The RPL for the G.8032 ring is between A and B, where B is the RPL owner. 0 to 3 Ring Example is also 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 allow a form of load balancing. The example serves to illustrate that service encapsulations and ring encapsulation can be mixed in various combinations.

Note:

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 a small amount of transfer time (signaling time after detection).

Figure 8:  0 to 3 Ring Example 

The following is a sample configuration output for G.8032 ring for the preceding figure.

Step #1 - Configure G.8032 ring Paths and Control MEPs used for failure detection on ring ports.

Sample Configuration:

configure eth-ring 1
     description "Ring PBB BLUE on Node B"
     revert-time 100
     guard-time 5
     ccm-hold-time down 100 up 200
     rpl-node owner
     path a 1/1/1 raps-tag 100 // CC Tag 100
          description "To A ring link"
          rpl-end
          eth-cfm
               mep 1 domain 1 association 1 direction down  // Control MEP
                    no shutdown
               ccm-enable
               control-mep
               exit
          exit
          no shutdown  // would allow protect switching
                // in absence of the "force" cmd
     exit
     path b 6/6/2 raps-tag 100 //Tag 100
          description "to D Ring Link"
          eth-cfm
               mep 1 domain 1 association 1 direction down
                    no shutdown
                         ccm-enable
                         control-mep
               exit
          exit
          no shutdown
     exit
no shutdown
exit

Step #2 - Configure VPLS service used for G.8032 control instances (identified with VID tag 100 and 500) used to exchange R-APS messages for the two control instances created on the ring.

configure> service
     vpls 10 customer 1 create // Ring APS SAPs
          description "Ring Control VID 100"
          sap 1/1/1:100 eth-ring 1 create  // TAG for the Control Path a
          exit
          sap 6/6/2:100 eth-ring 1 create  // TAG for the Control Path b
          exit
          no shutdown
     exit
configure> service
     vpls 40 customer 1 create //Data Channel on Ring
          description "Ethernet Ring 1 VID 500"
          sap 1/1/1:500 eth-ring 1 create   // TAG for the Data Channel Path a
          exit
          sap 6/6/2:500 eth-ring 1 create   // TAG for the Data Channel Path b
          exit
     exit
 

Step #3 - Configure VPLS data services that will use G.8032 for protection.

configure> service vpls 1001 // CPE traffic
          sap 3/1/2:400.1 create 
          // CPE SAP
          exit
 
          sap 6/6/1:2000 create
          // uplink SAP
          exit
 
          no shutdown
     exit
 
configure> service vpls 1001 // CPE traffic
          sap 2/2/1:100.50 create 
          // CPE SAP
          exit
 
          sap 6/6/1:600 create
          // uplink SAP
          exit
 
          no shutdown
     exit

2.11.2. G.8032 — 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, as shown in Figure 9.

Note:

The platforms as described in this document cannot be used as the interconnection nodes. They can be used only as the ring nodes in the sub-ring.

Figure 9:  Major Ring and Sub-ring Scenario 

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 interconnection nodes.

Figure 10:  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.11.3. G.8032 — Virtual and Non-virtual Channel

The following is a sample sub-ring using virtual-link configuration on Node C, interconnecting node.

eth-ring 2
        description "Ethernet Sub Ring on Ring 1"
            interconnect ring-id 1 // Link to Major Ring 1
                propagate-topology-change 
            exit
        exit
        path a 1/1/3 raps-tag 100 // Ring control uses VID 100
            eth-cfm
 
                mep 9 domain 1 association 4
                    ccm-enable
                    control-mep
                    no shutdown
                exit
            exit
            no shutdown
        exit
        no shutdown
    exit
sub-ring non-virtual-link // Not using a virtual link
 
# Control Channel for the Major Ring ERP1 illustrates that Major ring 
# control is still separate from Sub-ring control
  vpls 10 customer 1 create
      description "Control VID 10 for Ring 1 Major Ring"
      stp shutdown
      sap 1/1/1:10 eth-ring 1 create
          stp shutdown
          exit
      sap 1/1/4:10 eth-ring 1 create
          stp shutdown 
          exit
      no shutdown
  exit 
 
# Data configuration for the Sub-Ring
 
  vpls 11 customer 1 create
      description "Data on VID 11 for Ring 1"
      stp shutdown 
      sap 1/1/1:11 eth-ring 1 create // VID 11 used for ring
          stp shutdown 
      exit
      sap 1/1/4:11 eth-ring 1 create
          stp shutdown 
      exit
      sap 1/1/3:11 eth-ring 2 create // Sub-ring data
          stp shutdown 
      exit
      sap 3/2/1:1 create 
      description "Local Data SAP"
          stp shutdown 
      no shutdown
  exit
 
# Control Channel for the Sub-Ring using a virtual link. This is 
# a data channel as far as Ring 1 configuration. Other Ring 1 
# nodes also need this VID to be configured. 
 
  vpls 100 customer 1 create
      description "Control VID 100 for Ring 2 Interconnection"
      split-horizon-group "s1" create //Ring Split horizon Group
      exit
      stp shutdown 
      sap 1/1/1:100 split-horizon-group "s1" eth-ring 1 create
          stp shutdown 
      exit
      sap 1/1/4:100 split-horizon-group "s1" eth-ring 1 create
          stp shutdown 
      exit
      sap 1/1/3:100 eth-ring 2 create
          stp shutdown 
      exit
      no shutdown
  exit 

2.11.3.1. G.8032 — Ethernet Ring Sub-ring Using Non-virtual Link

Figure 11 shows 0 to 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.

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

The following is a sample sub-ring using non-virtual link configuration 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 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.11.4. G.8032 — 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.

Up MEPs on service SAPs that multicast into the service and monitor the active path may be used to monitor services.

2.11.5. G.8032 — QoS Considerations

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.

Note:

The operator must configure appropriate ingress QoS policies to ensure that R-APS messages get appropriate QoS treatment and is processed and/or transmitted without delays to enable better failover time.

2.11.6. G.8032 — Service and Solution Combinations

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

  1. Only ports in access mode and access-uplink mode can be configured as eth-ring paths.
  2. Dot1q and QinQ ports are supported as eth-ring path members.

2.11.7. G.8032 — Configuration Guidelines

The following are the configuration guidelines for G.8032:

  1. Service level MEPs are not available on all SAPs tied to an eth-ring instance on a port.
  2. G.8032 instances cannot be configured over a LAG.
  3. For 7210 SAS-D and 7210 SAS-Dxp devices, to improve the service fail-over time due to failures in the ring path, fast flood is enabled by default. On a failure detection in one of the paths of the eth ring, along with MAC flush the system starts to flood the traffic onto the available path.No explicit user configuration is needed for this and it does not affect scaling for filters/ACLs.
  4. For 7210 SAS-D and 7210 SAS-Dxp devices, Down MEPs used with services and G.8032 share common hardware resources.
  5. All 7210 SAS-K platforms support fast-flood by default to improve service fail-over time. It does not require explicit user configuration and does not share resources with either Filters/ACLS or Service Down MEPs.

2.12. Layer 2 Control Processing

Operators providing Epipe and VPLS services need to be able to transparently forward Layer 2 control processing (L2CP) control frames received from the customers. This allows their customers to run these control protocols between the different locations that are part of the Layer 2 VPN service. The 7210 SAS platforms provide the user with the following capability:

  1. An option to tunnel, discard, or peer for EFM OAM, LLDP, Dot1x, and LACP.
  2. BPDU translation and Layer 2 protocol tunneling support for xSTP and CISCO control protocols. This is supported only in a VPLS service. For more information, see the L2PT and BPDU Translation.
Note:

The CDP, VTP, DTP, PAgP, and UDLD management protocols are forwarded transparently in an Epipe service.

By default, LACP, LLDP, EFM OAM, and Dot1x L2CP untagged packets are discarded if the protocol is not enabled on the port where these frames are received. The user has an option to enable peering by enabling the protocol on the port and configuring the appropriate parameters for the protocol. The user also has an option to tunnel these packets using an Epipe or VPLS service.

In a VPLS service, the Layer 2 control frames are sent out of all the SAPs configured in the VPLS service. Nokia recommends using this feature carefully and only when a VPLS is used to emulate an end-to-end Epipe service (that is, an Epipe configured using a three-point VPLS service, with one access SAP and two access-uplink SAP/SDPs for redundant connectivity). That is, if the VPLS service is used for multi-point connectivity, Nokia does not recommend using this feature. When a Layer 2 control frame is forwarded out of a dot1q SAP or a QinQ SAP, the SAP tags of the egress SAP are added to the packet.

The following SAPs can be configured for tunneling the untagged L2CP frames (corresponding protocol tunneling needs to be enabled on the port):

  1. If the port encapsulation is null, the user has an option to tunnel these packets by configuring a null SAP on a port.
  2. If the port encapsulation is dot1q, the user has an option to use dot1q explicit null SAP (for example, 1/1/10:0) or a dot1q default SAP (for example, 1/1/11:*) to tunnel these packets.
  3. If the port encapsulation is QinQ, the user has an option to use 0.* SAP (for example, 1/1/10:0.*) to tunnel these packets.

In addition to the preceding protocols, protocols not supported on 7210 (for example, GARP, GVRP, ELMI, and others) are transparently forwarded in case of a VPLS service. These protocols are transparently forwarded if a null SAP, dot1q default SAP, dot1q explicit null SAP or 0.* SAP is configured on the port and the received packet is untagged. If the received packet is tagged and matches the tag of any of the SAPs configured on the port, it is forwarded in the context of the SAP and the service. Otherwise, if the received packet is untagged and none of the null or dot1q default or dot1q explicit null or 0.* SAP is configured, it is discarded.

If a 7210 receives a tagged L2CP packet on any SAP (including null, dot1q, dot1q range, QinQ, QinQ default), it is forwarded transparently in the service similar to normal service traffic (xSTP processing behavior is different in VPLS service and is listed as follows).

The xSTP processing behavior in a VPLS service is as follows:

  1. If xSTP is enabled in the service, and if the tag in the STP BPDU matches the tag of the configured SAP, the received xSTP BPDU is processed by the local xSTP instance on the node for that service when xSTP is enabled on the SAP, and discarded when xSTP is disabled on the SAP.
  2. If the tags do not match, xSTP BPDU packets are transparently forwarded in the service similar to normal service traffic.
  3. If xSTP is disabled in the service, STP BPDU packets are transparently forwarded in the service similar to normal service traffic.

Table 9 lists the L2CP support on 7210 SAS platforms.

Table 9:  L2CP Support on the 7210 SAS 

Packet Type

7210 SAS-D, 7210 SAS-Dxp

7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C

LACP

Option to tunnel or discard or peer

Option to tunnel or discard or peer

Dot1x

Option to tunnel or discard or peer

Option to tunnel or discard or peer

LLDP

Option to tunnel or discard or Peer 1

Option to tunnel or discard or peer 1

EFM

Option to tunnel or discard or peer

Option to tunnel or discard or peer

L2PT

Supported

Supported

BPDU Tunneling

Supported

Supported

xSTP

Option to peer or tunnel

Option to peer or tunnel

    Note:

  1. Refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Interface Configuration Guide for more information about the options available for LLDP tunneling.

2.13. Service Creation Process Overview

This section provides an overview of the service creation process with access-uplink ports.

Figure 12 shows the overall process to provision core and subscriber services.

Figure 12:  Service Creation and Implementation Flow 

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

  1. Phase 1: Core Network Construction
  2. Phase 2: Service Administration
  3. Phase 3: Service Provisioning

2.13.1.1. Phase 1: Core Network Construction

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

  1. Build the IP or IP/MPLS core network.
  2. Configure routing protocols.

2.13.1.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.

  1. Configure group and user access privileges.
  2. Build templates for QoS, filter and/or accounting policies needed to support the core services.

2.13.1.3. Phase 3: Service Provisioning

For service provisioning, the following tasks should be completed.

  1. Provision customer account information.
  2. If necessary, build any customer-specific QoS, filter, or accounting policies.
  3. Provision the customer services on the service edge routers by defining SAPs, and binding policies to the SAPs.

2.13.2. Configuration Notes

This section describes service configuration caveats.

2.13.2.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.

  1. Create customer accounts.
  2. Create template QoS, filter, scheduler, and accounting policies.

Subscriber services tasks include the following.

  1. Configure interfaces (where required) and SAPs.
  2. Create exclusive QoS and filter policies.