Services Overview

This chapter provides an overview of the 7705 SAR subscriber services, service model, and service entities. Additional details on the individual subscriber services are found in subsequent chapters.

Topics in this chapter include:

Introduction to Services on the 7705 SAR

Topics in this section include:

Overview

A service is a type of telecommunications connection from one place to another. These telecommunications connections have the particular attributes and characteristics that are needed to provide a specific communications link through which an information flow or exchange can occur. The 7705 Service Access Router (7705 SAR) offers VLL services, Layer 2 multipoint VPN services (VPLS), Layer 3 MPLS VPN services (VPRN), and Layer 3 routed/IP services.

The 7705 SAR service model uses (logical) service entities to construct a service. These logical entities provide a uniform, service-centric configuration, management, and billing model for service provisioning (see Nokia Service Model for more information). Many services can be created on the same 7705 SAR at the same time, and each service is uniquely identified by a service ID.

The 7705 SAR offers Virtual Leased Line (VLL) services (also referred to as pseudowire (PW) services or pipes), which emulate a Layer 1/2 entity, such as a wire or a leased line. These emulated services provide connectivity between a service access point (SAP) on one 7705 SAR and on another SAP on the same router, or on a remote 7705 SAR or 7750 SR. VLL services offer SAP logical entities—such as a VLAN or a virtual connection—Layer 2 visibility or processing (IMA termination). A SAP is the point where customer traffic enters and exits the service.

A connection between two SAPs on the same router is known as a local service. A connection between SAPs on a local and a remote router is known as a distributed service. SAP-to-SAP connections are supported for ATM, Ethernet, FR, HDLC, and TDM VLLs.

The 7705 SAR also supports the aggregation of multiple ATM VCC SAPs into a single aggregation group within a service. Aggregation groups enable service providers to make more efficient use of the ATM VCC VLL services that are deployed in a network.

Distributed services use service destination points (SDPs) to direct traffic from a local router to a remote router through a service tunnel. An SDP is created on the local router and identifies the endpoint of a logical unidirectional service tunnel. Traffic enters the tunnel at the SDP on the local router and exits the tunnel at the remote router. Hence a service tunnel provides a path from a 7705 SAR to another service router, such as another 7705 SAR or a 7750 SR. Because an SDP is unidirectional, two service tunnels are needed for bidirectional communication between two service routers (one SDP on each router).

SDPs are configured on each participating 7705 SAR or service router (for example, a 7750 SR), specifying the address of the destination router, such as another 7705 SAR or service router. After SDPs are created, they are bound to a specific service. The binding process is needed to associate the far-end devices to the service; otherwise, far-end devices are not able to participate in the service.

The 7705 SAR also offers IES, VPLS, and VPRN services.

IES provides IP connectivity between customer access points. From the customer’s perspective, IES provides direct IP connectivity. The customer is assigned an IP interface and a SAP designates the customer access point where the customer IP device is connected—one SAP binding per IP interface. Supported SAP encapsulations are MC-MLPPP, PPP/MLPPP and null/dot1q/qinq Ethernet. SDP binding is not required because traffic is routed rather than being encapsulated in a tunnel.

A Virtual Private Routed Network (VPRN) consists of a set of customer sites connected to one or more PE routers. VPRNs are based on RFC 2547bis, which details a method of distributing routing information and forwarding data to provide a Layer 3 Virtual Private Network (VPN) service to end customers. VPRN traffic is transported over LDP and RSVP-TE tunnels, as well as static LSPs.

A Virtual Private LAN Service (VPLS) enables Layer 2 multipoint connections within an enterprise infrastructure. Supported SAP encapsulations are null/dot1q/qinq Ethernet (on the 6-port Ethernet 10Gbps Adapter card, 7705 SAR-X, 8-port Gigabit Ethernet Adapter card, and the 10-port 1GigE/1-port 10GigE X-Adapter card) and ATM (on the 4-port OC3/STM1 Clear Channel Adapter card).

Note: The 10-port 1GigE/1-port 10GigE X-Adapter card supports qinq only when it is in 10-port 1GigE mode.

VPLS traffic can also be transported over existing tunnel types like GRE tunnels, LDP tunnels, RSVP-TE tunnels, and static LSPs using SDPs. For the ATM SAPs, the Layer 2 Ethernet frames are encapsulated in llc-snap bridged PDUs, as per RFC 2684, widely referred to with the obsoleted RFC 1483.

Service Types

Services are commonly called customer or subscriber services. The 7705 SAR offers the following types of services, which are described in more detail in the referenced chapters:

  • Virtual Leased Line (VLL) services

    • ATM VLL (Apipe)—a pseudowire emulation edge-to-edge (PWE3) ATM service over MPLS, GRE, or IP tunnels on 7705 SAR nodes. See ATM VLL (Apipe) Services.

    • Circuit emulation VLL (Cpipe)—a PWE3 circuit emulation service over MPLS or GRE tunnels on 7705 SAR nodes. See Circuit Emulation VLL (Cpipe) Services.

    • Ethernet VLL (Epipe)—a PWE3 Ethernet service over MPLS or GRE tunnels for Ethernet frames on 7705 SAR nodes. See Ethernet VLL (Epipe) Services.

    • FR VLL (Fpipe)—a PWE3 FR service over MPLS or GRE tunnels for FR frames on 7705 SAR nodes. See Frame Relay VLL (Fpipe) Services.

    • HDLC VLL (Hpipe)—a PWE3 HDLC service over MPLS or GRE tunnels for HDLC frames on 7705 SAR nodes. See HDLC VLL (Hpipe) Services.

    • IP interworking VLL (Ipipe)—a PWE3 IP service between two hosts connected by any combination of point-to-point access circuits. IP interworking VLLs can operate over MPLS or GRE networks. Some typical examples are Ethernet SAP to Ethernet SAP, Ethernet SAP to MLPPP SAP, Ethernet SAP to LAG SAP, FR SAP to Ethernet SAP, or cHDLC SAP to Ethernet SAP. See IP Interworking VLL (Ipipe) Services.

  • Internet Enhanced Service (IES)

    • IES is used both as a direct Internet access service where the customer is assigned an IP interface for routed connectivity and for in-band management of the 7705 SAR. See Internet Enhanced Service.

  • Virtual Private LAN Service (VPLS)

    • VPLS provides a Layer 2 multipoint VPN service to end customers. VPLS includes Hierarchical VPLS (H-VPLS), which is an enhancement of VPLS that extends pseudowire-style signaled or static virtual circuit labeling outside the fully meshed VPLS core. The 7705 SAR can participate in hierarchical VPLS. In addition, the 7705 SAR supports management VPLS (mVPLS) via Rapid Spanning Tree Protocol (RSTP). See VPLS.

  • Virtual Private Routed Network Service (VPRN)

    • VPRN provides a Layer 3 VPN service to end customers. VPRN services provide MP-BGP peering with other PEs, configurable QoS policy and filtering, VRF import and export policies, and SGT-QoS marking. See VPRN Services.

Pseudowire Service Types lists the supported pseudowire (PW) service types. The values are as defined in RFC 4446.

Table 1. Pseudowire Service Types

PW Service Type (Ethertype)

Value

IP Layer 2 transport

0x000B

Ethernet tagged mode

0x0004

Ethernet raw

0x0005

HDLC

0x0006

ATM N-to-one VCC cell mode1

0x0009

ATM N-to-one VPC cell mode1

0x000A

ATM transparent cell transport mode

0x0003

SAToP E1

0x0011

SAToP T1

0x0012

CESoPSN basic mode

0x0015

CESoPSN TDM with CAS

0x0017

FR DLCI

0x0019

Note:

  1. ‟N-to-one” is expressed as ‟N-to-1” throughout this guide.

Service Policies

Common to all 7705 SAR connectivity services are policies that are assigned to the service. Policies are defined at the global level, then applied to a service on the router. Policies are used to define 7705 SAR service enhancements.

The types of policies that are common to all 7705 SAR connectivity services are SAP Quality of Service (QoS) policies and accounting policies. Filter policies are supported on network interfaces, Epipe and Ipipe SAPs, VPLS SAPs and SDPs (mesh and spoke), VPRN SAPs and spoke SDPs, IES SAPs and spoke SDPs, and IES in-band management SAPs.

  • SAP Quality of Service (QoS) policies allow for different classes of traffic within a service at SAP ingress and SAP egress.

    QoS ingress and egress policies determine the QoS characteristics for a SAP. A QoS policy applied to a SAP specifies the number of queues, queue characteristics (such as forwarding class, committed information rates, and peak information rates) 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 a single egress QoS policy can be associated with a SAP.

    QoS ingress and egress policies also apply to SAP aggregation groups.

  • Accounting policies define how to count the traffic usage for a service for billing purposes.

    The 7705 SAR routers provide a comprehensive set of service-related counters. Accounting data can be collected on a per-service, per-forwarding class basis, which enables network operators to accurately measure network usage and bill each customer for each individual service using any of a number of different billing models.

  • Filter policies, also referred to as access control lists (ACLs), allow selective blocking or forwarding of traffic that matches criteria that is set in the policy. The resulting action (block or forward) is applied to that traffic.

    Filter policies control the traffic allowed into a SAP or SDP, and are based on IP or MAC match criteria. The ability to configure and apply a filter depends on the combination of service, traffic type and direction, and entity type (SAP or SDP). Assigning a filter policy to a SAP or SDP is optional. Filter policies are identified by a unique filter policy ID. A filter policy must be created before it can be applied. A single ingress and a single egress filter policy can be assigned to a SAP (if supported), and a single ingress filter policy can be assigned to an SDP (if supported).

For more information about provisioning QoS policies, including queuing behaviors, see the 7705 SAR Quality of Service Guide. For information about configuring IP and MAC filter policies, see the 7705 SAR Router Configuration Guide.

Nokia Service Model

The 7705 SAR routers are deployed at the provider edge (PE). Services are provisioned on the 7705 SAR and other network equipment in order to facilitate the transport of telecommunications data across an IP/MPLS provider’s core network. The data is formatted so that it can be transported in encapsulation tunnels created using generic routing encapsulation (GRE), IP encapsulation, or MPLS label switched paths (LSPs).

The service model has four main logical components, referred to as (logical) service entities. The entities are: customers, service types, service access points (SAPs), and service destination points (SDPs) (see Service Entities). In accordance with the service model, the operator uses the (logical) service entities to construct an end-to-end service. The service entities are designed to provide a uniform, service-centric model for service provisioning. This service-centric design implies the following characteristics.

  • Many services can be bound to a single customer.

  • Many services can be bound to a single tunnel.

  • Tunnel configurations are independent of the services they carry.

  • Changes are made to a single service entity rather than to multiple ports on multiple devices. It is easier to change one tunnel rather than several services.

  • The operational integrity of a service entity (such as a service tunnel or service endpoint) can be verified by one operation rather than through the verification of dozens of parameters, thereby simplifying management operations, network scalability, and performance.

  • A failure in the network core can be correlated to specific subscribers and services.

  • The following policies are applied to various services:

    • QoS policies

    • accounting policies

    • filter policies (IP and MAC)

Additional properties can be configured for bandwidth assignments, class of service, and accounting and billing on the appropriate entity.

Service Entities

The basic (logical) service entities in the service model used to construct an end-to-end service are:

Service Entities and the Service Model shows an example of how the service entities relate to the service model. A subscriber (or customer) attachment circuit connects to a SAP. SDPs define the entrance and exit points of unidirectional service tunnels, which carry one-way traffic between the two routers (ALU-A and ALU-B). After SDPs have been configured, they are bound to a service, which is the final step in making the end-to-end service connection. In Service Entities and the Service Model, the entrance point is labeled SDP and the exit point is labeled Exit.

Traffic encapsulation occurs at the SAP and SDP. The SAP encapsulation types are SONET/SDH, Ethernet, and TDM. The SDP encapsulation types are MPLS, GRE, and IP. For information about SAP encapsulation types, see SAP Encapsulation Types and Identifiers. For information about SDP encapsulation types, see SDP Encapsulation Types.

Figure 1. Service Entities and the Service Model

Customers

The terms customers and subscribers are used synonymously. Every customer account must have a customer ID, 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.

Service Types

Service types provide the traffic adaptation needed by customer attachment circuits (ACs). This (logical) service entity adapts customer traffic to service tunnel requirements. The 7705 SAR provides six types of VLL service (that is, point-to-point MPLS-based emulation service, also called Virtual Private Wire Service (VPWS)):

  • ATM VLL (Apipe)

  • circuit emulation VLL (Cpipe)

  • Ethernet VLL (Epipe)

  • Frame relay VLL (Fpipe)

  • HDLC VLL (Hpipe)

  • IP interworking VLL (Ipipe)

The 7705 SAR also provides Ethernet layer (MAC-based) VPLS service (including management VPLS), as well as IP layer VPRN and IES services, that offer any-to-any connectivity within a Virtual Routing Domain or Generic Routing Domain, respectively.

Service Names

A service ID number must be associated with a service at the time of service creation. After the service is created, an optional service name can be assigned to the service for use by commands that reference the service.

Service Access Points (SAPs)

A service access point (SAP) is the point at which a service begins (ingress) or ends (egress) and represents the access point associated with a service. A SAP may be a physical port or a logical entity within a physical port. For example, a SAP may be a channel group within a DS1 or E1 frame, an ATM endpoint, an Ethernet port, or a VLAN that is identified by an Ethernet port and a VLAN tag. Each subscriber service connection on the 7705 SAR is configured to use only one SAP.

A SAP identifies the customer interface point for a service on a 7705 SAR router. Service Access Point (SAP) shows one customer connected to two services via two SAPs. The SAP identifiers are 1/1/5 and 1/1/6, which represent the physical ports associated with these SAPs. The physical port information should be configured prior to provisioning a service. See the 7705 SAR Interface Configuration Guide for more information about configuring a port. See Port and SAP CLI Identifiers for more information about identifiers.

The 7705 SAR supports the following services types: ATM pseudowires (Apipe), TDM pseudowires (Cpipe), IP pseudowires (Ipipe), Ethernet pseudowires (Epipe), FR pseudowires (Fpipe), HDLC pseudowires (Hpipe), IES, VPLS, and VPRN services. Customer access to these services is provided via SAPs. For each service type, the SAP has slightly different parameters.

In general, SAPs are logical endpoints that are local to the 7705 SAR and are uniquely identified by:

  • the physical Ethernet port, SONET/SDH port, or TDM channel group

  • the encapsulation type for the service (for example, ATM)

  • the encapsulation identifier (ID), which is, for example, the optional VLAN ID for Epipes, or the channel group ID for Cpipes

Depending on the encapsulation, a physical port or channel can have more than one SAP associated with it (for example, a port may have several circuit groups, where each group has an associated SAP). SAPs can only be created on ports or channels designated as ‟access” in the physical port configuration.

SAPs cannot be created on ports designated as core-facing ‟network” ports because these ports have a different set of features enabled in software.

Figure 2. Service Access Point (SAP)

SAP Encapsulation Types and Identifiers

The SAP encapsulation type is an access property of the Ethernet port, SONET/SDH port, or TDM channel group used for the service. It identifies the protocol that is used to provide the service.

The 7705 SAR supports three SAP encapsulation types:

Encapsulation types may have more than one option to choose from. For example, the options for TDM encapsulation type include ‟cem” (for circuit emulation service) and ‟atm” (for ATM service), among others.

For SAPs configured on the 16-port T1/E1 ASAP Adapter card, 32-port T1/E1 ASAP Adapter card, or 4-port DS3/E3 Adapter card, the cards must be configured to support the appropriate encapsulation methods before the encapsulation type can be configured. This is done using the mda-mode command. See the 7705 SAR Interface Configuration Guide for more information.

The encapsulation ID is an optional suffix that is appended to a port-id to specify a logical sub-element for a SAP. For example, port-id:qtag1 represents a port that can be tagged to use IEEE 802.1Q encapsulation (referred to as dot1q), where each individual tag can identify with an individual service. Similarly, port-id.channel-group:vpi/vci represents the encapsulation ID for an ATM SAP, which is a special case because it requires that a channel group identifier (which always uses the value 1) precede the VPI/VCI value.

Note:

  • Throughout this guide, the term ‟channel group” is often simplified to ‟channel”.

  • Do not confuse the term ‟encapsulation ID” (described here) with the term ‟Encapsulation ID”, which is used with the SNMP and MIBs for the 7705 SAR.

Ethernet Encapsulations

The following encapsulation service options are available on Ethernet ports:

  • null—supports a single service on the port; for example, where a single customer with a single service customer edge (CE) device is attached to the port.

  • dot1q—supports multiple services for one customer or services for multiple customers (see Multiple SAPs on a Single Port/Channel). An example of dot1q use may be the case where the Ethernet port is connected to a multi-tenant unit device with multiple downstream customers. The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header.

  • qinq— supports multiple services for one customer or services for multiple customers. The encapsulation IDs used to distinguish an individual service are the QinQ VLAN IDs in the IEEE 802.1ad header, producing a double-tagged frame. For more information about QinQ, see QinQ Support.

Figure 3. Multiple SAPs on a Single Port/Channel
Default SAP on a Dot1q and QinQ Port

The 7705 SAR supports default SAP functionality on dot1q- and qinq-encapsulated ports. On dot1q- and qinq-encapsulated ports where a default SAP is configured, all packets with Q-tags not matching any other explicitly defined SAPs are assigned to the default SAP for transport.

A default SAP is identified in the CLI by the use of the character ‟*” as a Q-tag, where the ‟*” means ‟all”. For example, port-id:vlan-x.* and port-id:*.* are default SAPs. The former case (vlan-x.*) is a specific example of the latter case (*.*), where the outer tag (vlan-x) matches an existing SAP VLAN ID. See Special QinQ SAP Identifiers for more information.

Note: On the 7705 SAR, the *.* notation for QinQ functions in the same way as the * notation for dot1q. This behavior is different from the 7750 SR implementation. On the 7750 SR, the ‟*.*” notation is used only for VPLS service as a capture SAP.

One of the applications where the default SAP feature can be used is for 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 (the use of a whole port) can be provided by a null-encapsulated port. A dedicated VLAN (not used by the user) can be used to provide CPE management.

In this type of environment, two SAPs logically 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 functions as a SAP on a null-encapsulated port.

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

  • The default SAP is supported only on VPLS and Epipe services and cannot be created in IES and VPRN services because IES and VPRN services cannot preserve VLAN tag markings.

  • For VPLS SAPs with STP enabled, STP listens to untagged and null-tagged BPDUs only. All other tagged BPDUs are forwarded like other customer packets. This is the same behavior as null-encapsulated ports.

  • IGMP snooping is not supported on a default SAP. By not allowing IGMP snooping of a default SAP, all IGMP packets will be transparently forwarded.

  • The default SAP and the SAP defined by explicit null encapsulation are mutually exclusive (for example, 1/1/1:* and 1/1/1:0 are mutually exclusive, and 1/1/2:1.* and 1/1/2:1.0 are mutually exclusive). This avoids conflict as to which SAP untagged frames should be associated with.

SONET/SDH Encapsulations

The following service encapsulation option is available on SONET/SDH ports:

  • atm—supports multiple service instances for one customer, as well as bridged llc-snap encapsulated ATM SAP termination to VPLS

TDM and Serial (TDM) Encapsulations

The following service encapsulation options are available on TDM and SDI ports:

  • atm—supports multiple services for one customer (TDM ports only)

  • cem—supports multiple services for one customer. Structured CEM service (circuit emulation service over packet switched network (CESoPSN (n ✕ DS0)) and unstructured CEM service (structure-agnostic TDM over packet (SAToP)) are supported. (TDM and SDI ports)

  • ipcp—supports a single IP service per TDM channel group on channelized DS1/E1 interfaces or on unstructured (unframed) E1 interfaces. Unframed E1 can be used for Ipipe support. Channelized interfaces are typically used for router interconnection using the point-to-point protocol (PPP). (TDM ports, and SDI V.35 and X.21 ports at super-rate speeds)

  • frame-relay (TDM ports, and SDI V.35 and X.21 ports at super-rate speeds)

  • cisco-hdlc (TDM on DS1/E1 ports, and SDI V.35 and X.21 ports at super-rate speeds)

  • hdlc (TDM on DS1/E1 ports, and SDI V.35 and X.21 ports at super-rate speeds)

Service Types and SAP Encapsulations—Summary

Service Types and SAP Encapsulations lists the SAP encapsulations available to 7705 SAR service types. These encapsulations apply to access-facing ports. The service (port) type and encapsulations are configured at the port level. See the 7705 SAR Interface Configuration Guide for more information about the cards and ports that support each of the service types.

Table 2. Service Types and SAP Encapsulations

Service (Port) Type

Encapsulation Option

Ethernet

null

Ethernet

dot1q

Ethernet

qinq

SONET/SDH

atm

TDM

cem

TDM

atm

TDM

ipcp

TDM

frame-relay

TDM

cisco-hdlc

TDM

hdlc

SAP Configuration Considerations

In addition to being an entry or exit point for service traffic, a SAP has to be configured for a service and, therefore, has properties. When configuring a SAP, consider the following.

  • A SAP is a local entity and is only locally unique to a specific device. The same SAP ID value can be used on another 7705 SAR.

  • There are no default SAPs. All subscriber service SAPs must be created.

  • The default administrative state for a SAP at creation time is administratively enabled.

  • When a SAP is deleted, all configuration parameters for the SAP are also deleted.

  • A SAP is owned by and associated with the service in which it is created.

  • An Ethernet port or channel with a dot1q encapsulation type means that 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 is 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. QinQ encapsulation means that the SAP is identified based on specific IEEE 802.1ad VLAN ID values.

  • A TDM circuit emulation service (for example, CESoPSN) requires a channel group. The channel group must be created before it can be assigned to a SAP.

  • An ATM service (for example, ATM N-to-1 VCC cell transport) on a 16-port T1/E1 ASAP Adapter card, 2-port OC3/STM1 Channelized Adapter card, or 4-port OC3/STM1 / 1-port OC12/STM4 Adapter card requires a channel group. For this case, the channel group requires the assignment of all 24 timeslots (T1) or 30 timeslots (E1). The timeslot assignments are made automatically after a channel group is configured for ATM encapsulation.

  • If a port or channel is administratively shut down, all SAPs on that port or channel will be operationally out of service.

  • A SAP cannot be deleted until it has been administratively disabled (shut down).

  • Each SAP can have one of the following policies assigned to it:

    • Ingress QoS policy

    • Egress QoS policy

    • Accounting policy

    • Ingress filter policy (for Epipe SAPs, Ipipe SAPs, VPLS SAPs, VPRN SAPs, IES SAPs, and IES in-band management SAPs)

    • Egress filter policy (for VPRN and IES SAPs, and for VPLS SAPs (Ethernet SAPs only))

Service Destination Points (SDPs)

An SDP identifies the endpoint of a logical unidirectional service tunnel. The service tunnel provides a path from one 7705 SAR to another network device, such as another 7705 SAR or a 7750 SR.

In more general terms, SDP refers to the service tunnel itself. The SDP terminates at the far-end router, which is responsible for directing the flow of packets to the correct service egress SAPs on that device.

Note: In this document and in command line interface (CLI) usage, SDP is defined as Service Destination Point. However, it is not uncommon to find the term SDP defined in several different ways, as in the following list. All variations of SDP have the same meaning:
  • Service Destination Point

  • Service Distribution Point

  • Service Destination Path

  • Service Distribution Path

  • Service Delivery Path

When an SDP is bound to a service, the service is referred to as a distributed service. A distributed service consists of a configuration with at least one SAP on a local node, one SAP on a remote node, and an SDP binding that binds the service to the service tunnel.

An SDP has the following characteristics.

  • An SDP is locally unique to a participating 7705 SAR. The same SDP ID can appear on other 7705 SAR routers.

  • An SDP uses the system IP address of the far-end edge router to locate its destination.

  • An SDP is not specific to any one service or to any type of service. After an SDP is created, services are bound to the SDP. An SDP can also have more than one service type associated with it.

  • All services bound to an SDP use the same SDP (transport) encapsulation type defined for the SDP (GRE, IP, or MPLS).

  • An SDP is a service entity used for service management. Even though the SDP configuration and the services carried within it 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 tunnel from the local device (typically, a 7705 SAR) to the far-end device (router) requires a return SDP tunnel from the far end back to the local device. Each device must have an SDP defined for every remote router to which it wants to provide service. The SDP must be created before a distributed service can be configured.

  • An SDP can be used to provide PW redundancy, where up to four spoke SDPs can be assigned to a service endpoint that acts as the managing entity to ensure service connection. See Pseudowire Redundancy.

SDP Binding

To configure a distributed service pointing from ALU-A to ALU-B, the SDP ID on the ALU-A side (see SDP Tunnel Pointing from ALU-A to ALU-B) must be specified during service creation in order to bind the service to the tunnel (the SDP). Otherwise, service traffic is not directed to a far-end point and the far-end 7705 SAR devices cannot participate in the service (there is no service). To configure a distributed service pointing from ALU-B to ALU-A, the SDP ID on the ALU-B side must be specified.

Figure 4. SDP Tunnel Pointing from ALU-A to ALU-B

Spoke and Mesh SDPs

There are two types of SDPs: spoke and mesh. The type of SDP defines how flooded traffic (or broadcast traffic, such as an ARP request) is propagated. For point-to-point PW/VLL services, spoke SDPs are the only way to bind services to the far-end router. For VPLS, mesh and spoke SDP bindings are allowed.

A spoke SDP that is bound to a service operates like a traditional bridge port. Flooded traffic that is received on the spoke SDP is transmitted to all the spoke SDPs, mesh SDPs, and SAPs to which it is connected. Flooded traffic is not transmitted back toward the port from which it was received.

In contrast, a mesh SDP that is bound to a service operates like a single bridge port. Flooded traffic received on a mesh SDP is transmitted to all spoke SDPs and SAPs to which it is connected. Flooded traffic is not transmitted to any other mesh SDPs or back toward the port from which it was received. This property of mesh SDPs is important for multi-node networks; mesh SDPs are used to prevent the creation of routing loops.

SDPs and BGP Route Tunnels

SDP can use BGP route tunnels to extend inter-AS support for Layer 2 and Layer 3 VPN services as defined in RFC 3107. An SDP can be configured based on service transport method (for example, GRE or MPLS tunnel). 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 LSP, RSVP-TE LSP or BGP route tunnel). This restriction is relaxed for some combinations of the transport methods when the mixed-LSP mode option is enabled on the SDP. See Mixed-LSP SDPs for more information.

For an 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/RSVP 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 configured to select an LSP to reach the PE node from the ASBR.

For more information about BGP route tunnels, see the 7705 SAR Routing Protocols Guide, ‟BGP Route Tunnels”.

SDP Encapsulation Types

The Nokia service model uses encapsulation tunnels (also referred to as service tunnels) through the core to interconnect 7705 SAR and SR routers. An SDP is a logical way of referencing the entrance to an encapsulation tunnel.

The following encapsulation types are supported:

Each SDP service tunnel has an entrance and an exit point for the pseudowires contained within it.

MPLS Encapsulation

Multiprotocol label switching (MPLS) encapsulation has the following characteristics.

  • An MPLS 7705 SAR router supports both signaled and non-signaled LSPs through the network.

  • Non-signaled paths are defined at each hop through the network.

An SDP has an implicit Maximum Transmission Unit (MTU) value because services are carried in encapsulation tunnels and an SDP is an entrance to the tunnel. The MTU is configurable (in octets), where the transmitted frame can be no larger than the MTU.

With MPLS, the MTU for the network port allows the addition of labels for transmission across the MPLS network. Ethernet frames that are sent out of a network port toward the MPLS core network (or a P router) are allowed to be oversized in order to include the MPLS labels without the need to fragment large frames. See MTU Settings for more information.

The following ways of configuring an MPLS tunnel are supported:

  • LDP signaled

  • RSVP-TE signaled

  • user-configured (static LSP)

GRE Encapsulation

Generic routing encapsulation (GRE) is one of the most common tunneling techniques in the industry. GRE tunnels are used to transport various network layer packets and are especially useful for facilitating pseudowires over IP networks. Since MPLS is a Layer 2.5 protocol, MPLS packets cannot be natively transported over a Layer 3 (IP) network. Therefore, GRE is the ideal alternative for applications where traffic must travel over a Layer 3 network; for example, in DSL applications.

For the HSDPA offload application (see HSDPA Offload), ATM pseudowires are transported over IP using GRE tunneling. For other applications, Ethernet and TDM pseudowires over GRE are also supported.

GRE SDPs are supported on all network interfaces.

GRE Format

In accordance with RFC 2784, a GRE encapsulated packet has the following format:

  • delivery header

  • GRE header

  • payload packet

Delivery Header

The delivery header is always an IP header.

GRE Header

The GRE header format is shown in GRE Header and described in GRE Header Descriptions.

Figure 5. GRE Header
Table 3. GRE Header Descriptions

Field

Description

C

Specifies whether there is a checksum in the header

If set to 1, both the checksum and reserved1 fields must be present

On the 7705 SAR, in the network egress (transmit) direction, the C bit is always set to 0; therefore, the checksum and reserved1 fields are omitted from the header. The GRE header is therefore always 4 bytes (32 bits) in the network egress direction.

In the network ingress direction, the C bit validity is checked. If it is set to a non-zero value, the GRE packet is discarded and the IP discards counter is increased.

Reserved0

Indicates whether the header contains optional fields

Not applicable to the 7705 SAR—first 5 bits of the field are always set to 0 and bits 6 to 12 are reserved for future use and also set to 0 by the 7705 SAR

Ver

Always set to 000 for GRE

At network ingress, if a GRE packet is received with the version field set to any value other than 000, the packet is discarded and the IP discards counter is increased

Protocol Type

Specifies the protocol type of the original payload packet—identical to Ethertype with the only supported option being MPLS unicast (0x8847)

Checksum (optional)

Not applicable

Reserved1 (optional)

Not applicable

Payload Packet

The payload encapsulation format for pseudowires over GRE is shown in GRE Pseudowire Payload Packet over Ethernet and described in GRE Pseudowire Payload Packet Descriptions.

Figure 6. GRE Pseudowire Payload Packet over Ethernet
Table 4. GRE Pseudowire Payload Packet Descriptions

Field

Description

Eth

The Layer 2 transport header

The only Layer 2 protocol supported is Ethernet

MTU size depends on the encapsulation type (14 bytes for null encapsulation, 18 bytes for dot1q encapsulation, and 22 bytes for qinq encapsulation)

IP

Indicates the transport protocol

The Ethertype is always set to IP (0x800), and in case of a mismatch, the unexpected or illegal Ethertype counters are increased 1

GRE

Indicates the encapsulation protocol

PW header

The pseudowire header identifies a service within the GRE tunnel

CW (optional)

The pseudowire control word (CW) is a 32-bit (4-byte) field that is inserted between the VC label and the Layer 2 frame

For more information about the control word, see Pseudowire Control Word

PW payload

The PW payload is the payload of the service being encapsulated (Ethernet, ATM, or TDM)

Note:

  1. The only exception to the Ethertype is if the packets are address resolution protocol (ARP) packets. For information about ARP, see the 7705 SAR Router Configuration Guide.

At the network egress of the 7705 SAR, the source address of the IP header is always set to the system IP address. The destination IP address is set to the system IP address of the service router on which the GRE SDP is configured, the far-end interface address, or the loopback address. Using the system IP addresses to bring up the GRE session ensures that any IP link between the two routers can be used to transport GRE/IP packets. It may therefore be necessary to use static IP address configuration over DSL networks to ensure connectivity between the routers (especially if the DSL modem is in bridge mode).

GRE Fragmentation

IP fragmentation can be enabled for GRE tunnels. Services for which fragmentation is typically not available can make use of IP fragmentation performed at the IP layer of the GRE tunnel. The IP fragmentation feature can be enabled at the GRE tunnel ingress by enabling the allow-fragmentation command on the SDP. The IP fragmentation size limits are derived from the MTU of the network port used by the GRE tunnel.

At the GRE tunnel egress, IP reassembly can be performed as specified by a reassembly profile assigned to the network interfaces on which the GRE packets are expected to arrive. The IP reassembly function is performed on the IP fragments received at the GRE tunnel egress before any underlying service label is processed. A reassembly profile is used to specify the amount of buffer space allocated for the IP reassembly function and to configure a reassembly timeout. These parameters are configured for each forwarding class to isolate different types of GRE traffic.

Note: The GRE reassembly function is not supported for fragments of a single GRE packet that arrive on different MDAs. All fragments of a GRE packet must arrive on the same MDA.

When allow-fragmentation is enabled on an SDP, the current MTU algorithm is overwritten with the configured path MTU. The administrative MTU and operational MTU both show the specified MTU value. If the path MTU is not configured or available, the operational MTU is set to 2000 bytes, and the administrative MTU displays a value of 0. When allow-fragmentation is disabled, the operational MTU reverts to the previous value.

Fragmentation is supported on the following types of GRE SDPs:

  • VPLS

  • Layer 3 spoke SDP

  • Epipe

The GRE SDPs can be NGE-encrypted; however, the NGE interface must be Ethernet. Fragmentation is not supported on NGE PPP/MLPPP interfaces. See GRE Fragmentation for NGE Packets for more information.

IP packets that are transported over a Layer 3 spoke SDP using a fragmentation-enabled GRE tunnel are handled differently depending on the DF bit setting and the size of the packet.

  • If the packet DF bit setting is 0 (Fragment), the GRE fragment size is determined by the network port MTU value.

  • If the packet DF bit setting is 1 (Do not fragment), and the packet size is smaller or equal to the smaller value of either the operational MTU of the spoke SDP or the Layer 3 spoke SDP interface MTU (if configured), the packet is sent through the GRE tunnel.

  • If the packet DF bit setting is 1 (Do not fragment), and the packet size is larger than the smaller value of either the operational MTU of the spoke SDP or the Layer 3 spoke SDP interface MTU (if configured), the packet is discarded and an ICMP message ‟Fragmentation Needed and Don’t Fragment was Set” is sent back to the source IP address.

IP reassembly profiles are required to ensure that all packet fragments are received within an expected time frame for each forwarding class. When the reassembly profile timers expire, all fragments of the corresponding incomplete frame are dropped and a ‟Fragment Reassembly Time Exceeded” ICMP error message is sent to the source node.

Note: The system checks the reassembly queues every 64 ms in a constant loop, which may cause a maximum of 63 ms variation between the user-configured value and the actual detection time. For example, using the default configuration of 2000 ms, the system may check the reassembly queue timer at 1999 ms, in which case the timeout would not occur during that cycle and would instead take place during the next cycle at 2063 ms.

Traffic ingressing a GRE tunnel can use different forwarding classes and different queues. If multiple queues are transmitting fragments, a higher-priority queue could interrupt the transmission of fragments of a frame in a lower-priority queue by interleaving fragments of another frame. If the fragments from the different frames have similar IP identifiers, they could be reassembled incorrectly into one frame at the tunnel egress. To prevent this incorrect reassembly of frames, the 7705 SAR that is performing the IP fragmentation uses 4 bits of the 16-bit IP identifier to indicate the transmitting queue at the tunnel ingress. The IP identifier is part of the IP reassembly tuple, which also contains the protocol, source address, and destination address. Using the IP reassembly tuple, fragments of frames from different queues are always differentiated. However, reserving 4 bits in the IP identifier field leaves only 12 bits to act as a sequence number, which causes a shorter identifier wraparound. The time required for the IP identifier to wrap around is a function of the traffic rate on a specific queue at the GRE tunnel ingress.

If fragments are dropped along the GRE tunnel due to congestion or bit errors, the 7705 SAR that is performing the IP reassembly at the tunnel egress normally drops partially reassembled packets due to expiration of the reassembly timeout interval. If fragment loss occurs in the network along with an IP identifier wraparound due to a high packet rate, the IP reassembly block may incorrectly insert fragments of a new frame into a frame of older fragments that are waiting for timeout. When configuring the timeout interval, it is therefore important to factor in the pre-fragmentation frame rate for forwarding classes on a GRE tunnel. As a guideline, higher-priority packets should have shorter timeout intervals than other packets because their queue interruption at the ingress GRE tunnel is minimal, and the timeout intervals should be shorter than the transmission time of 4096 packets for that forwarding class.

The 7705 SAR does not support double fragmentation.

IP Encapsulation

IP encapsulation is added to the 7705 SAR in response to a growing demand for more pseudowire-based solutions in mobile backhaul. IP encapsulation is similar to GRE encapsulation but allows pseudowires to be transported natively over IP packets. Only static pseudowires are supported for IP SDPs because there is no label path to define except for the endpoints. The path is an IP routed path.

The 7705 SAR supports the transport of pseudowires over IP tunnels. IP Example of Pseudowire Payload Packet over Ethernet shows an example of an application using Apipes over IP over Ethernet.

Payload Packet

A typical payload encapsulation format for pseudowires over IP is shown in IP Example of Pseudowire Payload Packet over Ethernet and described in IP Pseudowire Payload Packet Descriptions.

Figure 7. IP Example of Pseudowire Payload Packet over Ethernet
Table 5. IP Pseudowire Payload Packet Descriptions

Field

Description

Eth

The Layer 2 transport header

The only Layer 2 protocol supported is Ethernet

MTU size depends on the encapsulation type (14 bytes for null encapsulation, 18 bytes for dot1q encapsulation, and 22 bytes for qinq encapsulation)

IP

Indicates the transport protocol

The only supported option is MPLS in IP (0x89)

The Ethertype is always set to IP (0x0800), and in case of a mismatch, the unexpected or illegal Ethertype counters are increased1

PW header

The pseudowire header identifies a service within the IP tunnel. The pseudowire header is like an MPLS header that has context only to the encapsulating and decapsulating LERs. This means that the IP transport network has no knowledge about the pseudowires that it carries. Only the edge LERs are aware of the pseudowire because the IPv4 Protocol Number field is set to 137 (0x89), indicating an MPLS unicast packet.

CW (optional)

The pseudowire control word (CW) is a 32-bit (4-byte) field that is inserted between the VC label and the Layer 2 frame

For more information about control word, see Pseudowire Control Word

ATM Cell #1 to ATM Cell #N

Indicates the payload of the service being encapsulated (ATM)

Note:

  1. The only exception to the Ethertype is if the packets are address resolution protocol (ARP) packets. For information about ARP, see the 7705 SAR Router Configuration Guide.

Spoke SDP Terminations

The 7705 SAR supports spoke SDP as termination points for IES and VPRN services. Spoke SDP Termination Support shows which service interfaces and spoke SDPs can be connected to each other. For example, an Epipe spoke SDP can connect to an IES or VPRN interface. See Spoke SDP Termination to IES and Spoke SDP Termination to VPRN for more information.

Table 6. Spoke SDP Termination Support

Epipe Spoke SDP

Epipe Spoke SDP Redundancy (standby-signal-master enabled)

IES Interface

VPRN Interface

VPLS Spoke SDP

VPLS Spoke SDP Redundancy (suppress-standby- signaling disabled)

Epipe Spoke SDP

Epipe Spoke SDP Redundancy (standby-signal-master enabled)

IES Interface

VPRN Interface

VPLS Spoke SDP

VPLS Spoke SDP Redundancy (suppress-standby- signaling disabled)

SDP Ping

Ping is an application that allows a user to test whether a particular host is reachable. SDP Ping is an application that allows a user to test whether a particular SDP endpoint is reachable.

SDP ping uses the SDP identifier that is stored in the 7705 SAR that originates the ping request. SDP ping responses can be configured to return through the corresponding return tunnel as a round-trip ping, or out-of band when unidirectional pings are requested. See the 7705 SAR OAM and Diagnostics Guide, ‟SDP Ping”, for more information.

SDP Keepalives

The SDP keepalive application allows a system operator to actively monitor the SDP operational state using periodic Nokia SDP Echo Request and Echo Reply messages. Automatic SDP keepalives work in a manner that is similar to a manual SDP ping command. The SDP Echo Request and Echo Reply messages provide a mechanism for exchanging far-end SDP statuses.

SDP keepalive Echo Request messages are only sent after the SDP has been completely configured and is administratively up and the 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.

The SDP is immediately brought operationally down when:

  • the Max Drop Count Echo Request messages do not receive an Echo Reply

  • a keepalive response is received that indicates an error condition

After a response is received that indicates the error has cleared and the Hold Down Time interval has expired, the SDP is eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP enters the operational state.

Configuring SDP keepalives on a specific SDP is optional. SDP keepalives have the following configurable keepalive parameters:

  • Hello Time

  • Message Length

  • Max Drop Count

  • Hold Down Time

  • Timeout

For information about configuring keepalive parameters, see Configuring SDPs.

Mixed-LSP SDPs

If mixed-LSP SDP mode is enabled on an SDP, a maximum of two LSP types can be configured on the SDP: a primary LSP and a secondary (backup) LSP. Two combinations are possible:

  • an RSVP-TE primary LSP backed up by an LDP LSP

  • an LDP primary LSP backed up by a BGP LSP

The config>service>sdp mpls>mixed-lsp-mode command is used to configure a mixed-LSP SDP.

Note: Mixed-LSP SDPs do not support static LSPs on either the primary or backup.

Mixed-LSP Mode of Operation

The service manager programs only one type of LSP in the line card, which activates it to forward service packets. The LSPs are programmed in the following priority order:

  1. RSVP-TE LSP type

    This is the highest-priority LSP type. Up to eight RSVP-TE LSPs can be entered by the user and programmed by the service manager in the ingress line card to load-balance service packets.

  2. LDP LSP type

    One LDP FEC is programmed by the service manager, but the ingress line card can use up to eight LDP ECMP paths for the FEC to load-balance service packets when ECMP is enabled on the node.

  3. BGP LSP type

    One RFC 3107-labeled BGP prefix is programmed by the service manager. The ingress line card can use more than one next hop for the prefix.

For an RSVP-TE/LDP SDP, the service manager programs the NHLFEs for the active LSP type, preferring the RSVP-TE LSP type over the LDP LSP type. If no RSVP-TE LSP is configured, or if all of the configured RSVP-TE LSPs go down, the service manager reprograms the line card with the LDP LSP, if available. If no LDP LSP is available, the SDP goes operationally down.

For LDP/BGP SDPs, the service manager prefers the LDP LSP type over the BGP LSP type. If no LDP LSP is configured or all configured LDP LSPs go down, the service manager reprograms the line card with the BGP LSP if it is available; otherwise, the SDP goes operationally down.

An LDP/BGP SDP differs from an RSVP/LDP SDP in the number of routes available. For any given /32 prefix, only a single route exists in the routing table: the IGP route or the BGP route. Therefore, only the LDP FEC or the BGP label route is active at any given time. The impact of this is that the tunnel table must be reprogrammed each time a route is deactivated and the other route is activated. In this scenario, the SDP revert-time command cannot be used because there is no situation where both LSP types are active for the same /32 prefix.

When a higher-priority LSP type becomes available, the service manager resets the SDP configuration to this LSP type when the revert timer expires or when the current active LSP fails, whichever occurs first. The length of time that the service manager must wait can be configured with the config>service>sdp mpls>mixed-lsp-mode>revert-time command. After the SDP has reverted to the higher-priority LSP, the service manager reprograms the line card accordingly. If the revert timer is configured with the infinite parameter, the service manager never resets the SDP to the highest-priority LSP type unless the current active LSP fails.

If the value of the revert time timer is changed, it takes effect when the timer is next activated. Any timer that is currently active when the value is changed is restarted with the new value.

Note: LDP uses a tunnel-down-damp timer that is set to 3 seconds by default. If the LDP LSP fails, the SDP reverts to the RSVP-TE LSP type after the expiry of this timer. For an immediate switchover, this timer must be set to 0 with the config>router>ldp>tunnel-down-damp-time command.

Multiple Load-balancing LSPs Under a Single SDP

Configuring multiple LSPs under a single SDP allows load distribution among multiple LSPs to the same destination. This load distribution is handled by the node without the need for any operator intervention. LSP additions or deletions result in automatic rehashing of services onto remaining LSPs, making it transparent to the operator. No new hashing algorithms are required; existing hashing algorithms are extended to select an LSP from multiple LSPs under an SDP.

Up to eight RSVP-TE or SR-TE LSPs can be configured under a single SDP. However, a mix of RSVP-TE and SR-TE LSPs is not supported. When the first LSP is configured under the SDP, all other LSPs configured under that SDP must be of the same type.

Multiple LSPs are only supported for SDPs configured for MPLS encapsulation.

High-Speed Download Packet Access Offload

The Mobile Radio Access Network (RAN) is rapidly growing to meet the increased demand in mobile services. This in turn increases demands on carriers to provide high-bandwidth, mobile broadband services. Today, at a typical cell site, 2G and 3G base stations are connected to high-cost, T1/E1 leased lines that are used to backhaul both voice and data traffic to the MTSO. For mission-critical, delay-sensitive, and low-bandwidth traffic such as voice, signaling, and synchronization traffic, it is vital that the high availability of these leased lines is ensured. SLA agreements also promise a high level of availability for customers.

Currently, however, best-effort traffic such as high-speed downlink packet access (HSDPA) is also switched over these SLA-enabled leased lines. HSDPA is a 3G mobile telephony communications service that allows UMTS networks to have higher data transfer speeds and capacity, allowing the mobile customer (end user) to browse the Internet or to use the mobile device. The increasing use of HSDPA is having a dramatic impact on the ability of the T1/E1 leased lines to scale with the traffic growth as well as on the operating costs of these lines.

Similar issues confront CDMA EVDO networks today.

Nokia provides a solution that enables mobile operators to keep their existing infrastructure (circuit-based leased lines), while gradually migrating to a packet-based infrastructure that will allow scalability, decrease costs, and ease the transition to the next-generation, all-IP network solutions.

HSDPA Offload

The Nokia solution is to make use of widely available DSL networks and split the traffic being backhauled. Mission-critical traffic (voice, signaling, synchronization) remains on the T1/E1 leased line circuits, while the best-effort, bandwidth-hungry HSDPA traffic is off-loaded to DSL networks.

The 7705 SAR-A is an ideal candidate for this scenario. The 7705 SAR-A is a small-scale version of the 7705 SAR product family, optimized for use in standalone small or midsized sites where traffic aggregation from multiple cell sites is not needed. For more information about the 7705 SAR-A, see the 7705 SAR-A Chassis Installation Guide.

7705 SAR-A HSDPA Offload Example shows an example of HSDPA offload with the 7705 SAR-A.

Figure 8. 7705 SAR-A HSDPA Offload Example

A 3G Node B is connected to a 7705 SAR-A over an ATM/IMA access port (SAP endpoint). An ATM SAP-to-SAP connection is set up in the 7705 SAR-A and a pseudowire is configured between the two endpoints to emulate local ATM switching. Traffic from the Node B enters an ATM/IMA port, the VCs transporting mission-critical traffic are locally switched (SAP-to-SAP) to another ATM/IMA port (SAP endpoint), and then switched over the leased lines to the MTSO.

Note: ATM SAP-to-SAP connections are supported between any T1/E1 ASAP port that is in access mode with ATM/IMA encapsulation and another port with the same encapsulation configuration. One endpoint of a SAP connection can be an IMA group, while the other endpoint can be on a single ATM port. ATM SAP-to-SAP connections are also supported between any two OC3/STM1 ports and between any T1/E1 ASAP port and OC3/STM1 port, as long as both SAPs support ATM.

For non-mission-critical traffic, for example, HSDPA traffic, an Ethernet interface on the 7705 SAR is connected to an external DSL modem. HSDPA traffic is interworked to ATM pseudowires and transported over the DSL network to the BRAS, then forwarded to the service router at the MTSO.

Failure Detection

Failure of the GRE SDP or the IP network it rides over can be detected by OAM tools as well as by BFD. With SAA, OAM tools can be configured to run periodically in order to facilitate faster failure detection. If a failure occurs, the ATM SAPs must be rerouted by the NSP NFM-P to the ATM ports used for backhauling the traffic. The mission-critical traffic is still serviced before the best-effort HSDPA traffic.

For information about OAM and SAA tools, see the 7705 SAR OAM and Diagnostics Guide. For information about BFD, see the 7705 SAR Router Configuration Guide.

ETH-CFM (802.1ag and Y.1731)

Topics in this section include:

Ethernet Connectivity Fault Management (ETH-CFM) is defined in two complementary standards: IEEE 802.1ag (dot1ag) and ITU-T Y.1731. Both standards specify protocols, procedures, and managed objects in support of transport fault management, including discovery and verification of the path, and detection and isolation of a connectivity fault for each Ethernet service instance.

Dot1ag and Y.1731 provide fault management (FM) functions for loopback, linktrace, and connectivity checks, as well as Up and Down MEP support for Ethernet SAPs (Epipe and VPLS), Ethernet spoke SDPs, and VPLS spoke/mesh SDPs, and facility MEP support for network interfaces.

Y.1731 fault management (Y.1731 FM) extends dot1ag CFM by providing functions for alarm indication signal (AIS) and ETH-Test testing. Furthermore, Y.1731 provides performance monitoring (Y.1731 PM) functions for delay and loss measurements. For more information on Y.1731 PM, see the ‟ITU-T Y.1731 Performance Monitoring (PM)” section in the 7705 SAR OAM and Diagnostics Guide.

For information about running Ethernet OAM tests, see the ‟ETH-CFM (802.1ag and Y.1731)” section in the 7705 SAR OAM and Diagnostics Guide.

The information in this section is specific to Ethernet SAPs and spoke and mesh SDPs, although most of it also applies to Ethernet network interfaces. For information about ETH-CFM support specific to network interfaces, see the 7705 SAR Router Configuration Guide, ‟ETH-CFM Support”.

CFM uses Ethernet frames that are distinguished by their Ethertype value and special Ethernet multicast address. For more information about the Ethernet frame, and the Ethertype and Ethernet multicast address values, see ETH-CFM Frame Format.

Using CFM, interoperability can be achieved between different vendor equipment in the service provider network, up to and including customer premises bridges.

Note: In the 7705 SAR CLI command hierarchy, commands for 802.1ag and Y.1731 are found under the eth-cfm context that appears at the following levels:
  • global (config>eth-cfm)

  • Epipe SAPs (config>service>epipe>sap>eth-cfm)

  • Epipe spoke SDPs (config>service>epipe>spoke-sdp>eth-cfm)

  • VPLS SAPs (config>service>vpls>sap>eth-cfm)

  • VPLS spoke SDPs (config>service>vpls>spoke-sdp>eth-cfm)

  • VPLS mesh SDPs (config>service>vpls>mesh-sdp>eth-cfm)

  • network interface (config>router>if>eth-cfm)

  • show (show>eth-cfm)

  • oam (oam>eth-cfm)

802.1ag and Y.1731 Terminology

802.1ag Terminology defines 802.1ag terms. Y.1731 Terminology illustrates the similarities and differences between Y.1731 and 802.1ag terms.

Table 7. 802.1ag Terminology

Term

Expansion

Definition

MA

Maintenance Association

A grouping of maintenance entities (MEs) that need to be managed as part of a service

MA-ID

Maintenance Association Identifier

A unique combination of MD index (md-index), MD level (level), and MA index (ma-index), where md-index, level, and ma-index are user-configured values

An MA is identified by its MA-ID

MD

Maintenance Domain

A set of Ethernet network elements or ports that are controlled by an operator, where boundaries are set by MEPs

MD level

Maintenance Domain level

A user-configured value of 0 to 7 representing a level of hierarchy within a CFM architecture. The value 7 is the highest MD level and 0 is the lowest.

The MD level is transmitted as part of the Ethernet CFM frame. A CFM message is said to have a higher MD level when its MD level value is higher than the MD value configured on the receiving MEP 7705 SAR.

Higher-level CFM messages are relayed as data frames by MEPs and ignored by the MEP entity.

ME

Maintenance Entity

An Ethernet port or endpoint that is managed as part of dot1ag OAM

An endpoint can be a SAP, spoke SDP, or mesh SDP (VPLS only)

MEP

Maintenance Association End Point

An (edge) endpoint that can terminate, respond to, or initiate the OAM messages for a configured MD-MA combination

MEP-ID

Maintenance Association End Point Identifier

A MEP is identified by its MEP-ID, which is a unique combination of MD index (md-index) and MA index (ma-index), where md-index and ma-index are user-configured values

MIP

Maintenance Association Intermediate Point

An intermediate point that can respond to OAM messages initiated by MEPs in the same MD. Connectivity fault management (CFM) messages destined for other MIPs or the destination MEP are transparent to MIPs.

MIPs are not supported on the 7705 SAR

Table 8. Y.1731 Terminology

Term

Expansion

Definition

MEG

Maintenance Entity Group

Same as MA but applies to Y.1731

MEG-ID

Maintenance Entity Group Identifier

Same as MA-ID but applies to Y.1731

MEG level

Maintenance Entity Group Level

Same as MD level but applies to Y.1731

Although MEG level and MD level are equivalent terms, there is no Y.1731 equivalent to an MD

MEP

Maintenance Association End Point

Same as MEP for 802.1ag

MDs, MD Levels, MAs, and MEPs (802.1ag)

Maintenance domains (MDs) and maintenance associations (MAs) are configured at the global level. Maintenance association endpoints (MEPs) are configured at the service level.

An MD is a set of network elements that have a common CFM OAM purpose. MDs are identified by their MD index and can be given an MD name. An MD is assigned a maintenance domain level (MD level). There are eight MD levels. MD levels are used to set up a messaging hierarchy for the CFM architecture.

An MA consists of up to eight MEPs (one local and up to seven remote) for Up MEPs on Epipe and VPLS services and two MEPs (one local and one remote) for Down MEPs on Epipe and VPLS services. The MA and the service are associated by configuring the MA bridge identifier parameter to have the same value as the service ID of the service that supports the MEPs. MAs are identified by their MA index and can be given an MA name. The MA is used to verify the integrity of a single service instance.

A MEP is configured as part of an Ethernet SAP, spoke SDP, or mesh SDP (VPLS only). MEPs can generate or terminate CFM OAM messages. MEPs only communicate within the same MD level, where the value of the MD level (0 to 7) is carried in a CFM OAMPDU. MEPs are identified by their MEP identifier and MA-ID. The MA-ID is configured at the global level.

MEPs and MAs shows a high-level view of MEPs in a CFM-enabled network. Two MAs are shown. The endpoints of MA 1 are MEPs 1 and 2, while MEPs 3 and 4 are the endpoints for MA 2.

For more information about MEP support, see Ethernet OAM.

Figure 9. MEPs and MAs

MEG Levels, MEGs, and MEPs (Y.1731)

On the 7705 SAR, the implementation of Y.1731 Fault Management (FM) is similar to that of dot1ag CFM, except that Y.1731 does not have a maintenance domain (MD). For Y.1731 and 802.1ag, the following terms are equivalent:

  • MEG level is equivalent to MD level

  • MEG is equivalent to MA

  • a Y.1731 MEP is equivalent to a dot1ag MEP

To access Y.1731 functions, including Y.1731 Performance Monitoring (PM) functions, configure a MEP to have the domain format set to none and the association format set to icc-based or string (the string keyword enables the Y.1731 MEP to interoperate with a dot1ag MEP).

ETH-CFM Frame Format

ETH-CFM OAMPDU messages for 802.1ag and Y.1731 use a standard Ethernet frame (see ETH-CFM Frame Format). The parts of the frame are described below.

Figure 10. ETH-CFM Frame Format

Destination and Source Addresses

The destination and source MAC addresses of the CFM message must match at the send and the receive routers. For example, a 7705 SAR-initiated ETH-CFM message would use the spoke SDP MAC address of the 7705 SAR as the source MAC address and the spoke SDP MAC address of the far-end router as the destination MAC address. At the far end, the source and destination MAC addresses would be the reverse of the near end.

An exception to the matching source-destination MAC address requirement occurs for linktrace and continuity messages, where the destination MAC address is set to a multicast group address. The designated multicast group address for linktrace and CCM is 01-80-C2-00-00-3x; where x represents the maintenance domain (MD) level (for 802.1ag) or the MEG level (for Y.1731). For example, a dot1ag CCM message destined for 01-80-C2-00-00-31 corresponds to MD level 1.

CCM packets using source-destination multicast MAC addresses are for user-initiated messages only (loopbacks).

Ethertype (T)

If dot1q or qinq encapsulation is not configured, the Ethertype value is 0x8902 and there are no VLAN tags. If dot1q or qinq encapsulation is configured, the VLAN tag (Ethertype value 0x8100) is present and is followed by the Ethertype value of 0x8902, which indicates ETH-CFM messages. The Ethertype is not hard-coded to 0x8100 and can be changed via the port configuration command.

VLAN/dot1p

The Vlan/Dot1p tag is the VLAN/dot1p identifier. If null encapsulation is configured (for Ethernet SAPs or spoke or mesh SDP bindings to a VC-type, ether or vlan), the frame is tagged with NULL.

ETH-CFM OAMPDU

The contents of the Ethernet OAMPDU depend on whether dot1ag or Y.1731 standards are being used. For information about the dot1ag or Y.1731 OAMPDU, see ETH-CFM OAMPDU.

FCS

The FCS is the frame check sequence field.

ETH-CFM OAMPDU

As shown in ETH-CFM OAMPDU Message, each ETH-CFM OAMPDU message contains the following fields:

  • MD level or MEG level: user-configured value, 0 to 7

  • version: current version is 0

  • opcodes: as defined in IEEE 802.1ag and Y.1731 standards, for messages such as:

    • Continuity Check Message (CCM)

    • Loopback Message (LBM)

    • Loopback Reply (LBR)

    • Linktrace Message (LTM)

    • Linktrace Reply (LTR)

  • flags: as defined in IEEE 802.1ag and Y.1731 standards

  • one or more TLVs, which include:

    • End TLV

    • Data TLV

    • Reply Ingress TLV

    • Reply Egress TLV

    • LTM egress identifier TLV

    • LTR egress identifier TLV

    • Test TLV

Figure 11. ETH-CFM OAMPDU Message

CFM Frame Processing

CFM Frame Processing shows whether a CFM frame received by various MEP types is processed. Frames that are processed are extracted from the datapath for CFM processing; unprocessed frames are treated as user traffic and follow the user traffic rules.

Table 9. CFM Frame Processing

MEP Details

Received CFM Frame Treatment

MEP Type

Direction

VC-Type

Port

Untagged

Tagged 1

Spoke SDP

Down

Raw

Any

Processed

Not processed

VLAN

Any

Not processed

Processed

Up

Raw

Any

Processed

Not processed

VLAN

Any

Not processed

Processed

Mesh SDP

Down

Raw

Any

Processed

Not processed

VLAN

Any

Not processed

Processed

Up

Raw

Any

Processed

Not processed

VLAN

Any

Not processed

Processed

SAP

Down

Any

Dot1q or QinQ

Not processed 2

Processed

Any

Null

Processed

Not processed

Up

Any

Dot1q or QinQ

Not processed

Processed

Any

Null

Processed

Not processed

Notes:

  1. Tagged frames are single-tagged frames (dot1q) or double-tagged frames (qinq).

  2. Untagged frames received on a dot1q-encapsulated port are processed by the Epipe or VPLS pseudowire configured to handle untagged frames. The SAP identifier uses VLAN ID 0, also referred to as SAP 0 (for example, 1/1/2:0). Untagged frames are also processed on the *.* QinQ SAP, and on a vlan-x.0 QinQ SAP only if the outer tag matches.

Processing SAP 0 and SAP 0.* OAM Packets

The following points describe the processing of OAM packets on SAP 0 (dot1q) and SAP 0.* (qinq). SAP 0.0 is not supported on OAM packets.

  • the 7705 SAR transmits untagged OAM frames on SAP 0 and SAP 0.*

  • the 7705 SAR does not process OAM frames tagged with VLAN ID 0 or VLAN ID 0.* on a port configured with null encapsulation

  • the 7705 SAR processes double-tagged or triple-tagged OAM frames under the following configuration scenario: there is a SAP Up MEP on a dot1q- or qinq-encapsulated port, using SAP 0 or 0.*, and having VC-type VLAN

    In this case, the top VLAN tag is removed and the bottom VLAN tag is assumed to be SAP 0 or 0.*. If the bottom VLAN tag is not SAP 0 or 0.*, the VLAN ID is changed to 0. If the frame is an OAM frame, double-tagged (or triple-tagged), the frame is extracted from the SAP Up MEP and the reply is with a single-tagged frame with its VLAN ID set to 0.

  • on a SAP Down MEP (dot1q or qinq), untagged frames are processed on SAP 0 or 0.*

MEG-ID and ICC-Based Format

Similar to an 802.1ag MA-ID, a Y.1731 MEG-ID uniquely identifies a group of MEs that are associated at the same MEG level in one administrative domain. The features of MEG-IDs are:

  • each MEG-ID must be globally unique

  • if the MEG may be required for path setup across interoperator boundaries, then the MEG-ID must be available to other network operators

  • the MEG-ID should not change while the MEG remains in existence

  • the MEG-ID should be able to identify the network operator that is responsible for the MEG

The 7705 SAR supports the ITU Carrier Code (ICC-based) MEG-ID format (TLV value 32). The generic and ICC-based MEG-ID formats are defined in the ITU-T Y.1731 standard. ICC-based MEG-ID Format shows the ICC-based MEG-ID format.

The MEG-ID value has exactly 13 characters and consists of two subfields, the ITU Carrier Code (ICC) followed by a Unique MEG-ID Code (UMC). The ITU Carrier Code consists of between 1 and 6 left-justified characters (alphabetic or leading alphabetic with trailing numeric). The UMC code immediately follows the ICC and consists of between 7 and 12 characters, with trailing NULLs (if necessary to complete the 13 characters).

The UMC is the responsibility of the organization to which the ICC has been assigned, provided that uniqueness is guaranteed.

Figure 12. ICC-based MEG-ID Format

ETH-CFM Functions and Tests

The following list of ETH-CFM functions applies to both dot1ag and Y.1731 Ethernet OAM:

  • ETH-CFM—ETH-CFM can be enabled or disabled on a SAP, spoke SDP, or mesh SDP (VPLS only)

  • MD levels—eight MD levels can be assigned

  • MD name—the following MD name formats are supported:

    • none (no MD name; used for specifying a Y.1731 functionality)

    • DNS name

    • MAC address and 2-octet integer

    • character string

  • MAs—MAs for each MD level can be configured, modified, or deleted

    • each MA is defined by a unique combination of MD index, MD level, and MA index. This unique combination of values is called the MA identifier (MA-ID).

    • the following MA name formats are supported:

      • primary VLAN ID (VID)

      • character string (when used with MD name format none, specifies Y.1731 interoperability with 802.1ag)

      • 2-octet integer

      • RFC 2685, Virtual Private Networks Identifier

      • ICC-based (used for specifying a Y.1731 functionality)

    • when a VID is used as the MA name, CFM will not support VLAN translation because the unique MA-ID must match all the MEPs

    • the default format for an MA name is a 2-octet integer; integer value 0 means that the MA is not attached to a VID.

  • MEPs—Up and Down MEPs on a SAP, spoke SDP, or mesh SDP

    • MEPs can be configured, modified, or deleted for each MD level (both associations for the Up or Down MEP are with the same bridge port as described in Section 19.2.1 of IEEE Standard 802.1ag-2007)

    • each MEP is uniquely identified by its MEP identifier and MA-ID combination

  • MEP creation—MEP creation on a SAP is allowed only for Ethernet ports (with null, dot1q, or qinq encapsulations)

ETH-CFM Ethernet OAM Tests

This section describes Ethernet OAM tests for ETH-CFM on the 7705 SAR, including:

  • loopbacks

  • linktrace

  • throughput measurement

  • continuity check

  • remote defect indication

  • alarm indication signal

  • Ethernet (signal) test

Note: The 7705 SAR also supports Ethernet Bandwidth Notification (ETH-BN) on the client side. For information, see the 7705 SAR OAM and Diagnostics Guide, ‟ITU-T Y.1731 Ethernet Bandwidth Notification (ETH-BN)”.
Loopback

The loopback (LB) function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Loopback Message (LBM) is generated by a MEP to its peer MEP. Both dot1ag and dot3ah loopbacks are supported. The loopback function is similar to IP or MPLS ping in that it verifies Ethernet connectivity between the nodes on a per-request basis. That is, it is non-periodic and is only initiated by a user request.

In Dot1ag Loopback Test, the line labeled LB represents the dot1ag loopback message between the 7750 SR (source) and 7705 SAR (target). The 7750 SR-generated LBM is switched to the 7705 SAR, where the LBM is processed. After the 7705 SAR generates the Loopback Reply message (LBR), the LBR is switched over the PW to the 7750 SR.

The following loopback-related functions are supported:

  • loopback message functionality on a MEP can be enabled or disabled

  • MEP—supports generating loopback messages and responding to loopback messages with loopback reply messages

  • displays the loopback test results on the originating MEP

Figure 13. Dot1ag Loopback Test
Linktrace

The linktrace (LT) function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Linktrace Message (LTM) is originated by a MEP and targeted to a peer MEP in the same MA and within the same MD level. Its function is similar to IP traceroute. The peer MEP responds with a Linktrace Reply (LTR) message after successful inspection of the LTM.

The following linktrace related functions are supported:

  • enables/disables LT functions on a MEP

  • MEP—supports generating LTMs and responding with LTR messages

  • displays linktrace test results on the originating MEP

Throughput Measurement

Throughput measurement is performed by sending frames to the far end at an increasing rate (up to wire speed) and measuring the percentage of frames received back. In general, the rate is dependent on frame size; the larger the frame size, the lower the rate.

The Y.1731 specification recommends the use of unicast ETH-LB and ETH-Test frames to measure throughput.

On the 7705 SAR, LBM processing and LBR generation are enhanced and occur on the datapath, allowing the 7705 SAR to respond to loopback messages at wire speed and making in-service throughput tests possible. Therefore, if the 7705 SAR receives LBMs at up to wire speed, it can generate up to an equal number of LBRs.

In order to process LBMs at wire speed, there must be either no TLVs or a single TLV (which is a data TLV) in the LBM frame. The End TLV field (0) must be present and the frame can be padded with data after the End TLV field in order to increase the size of the frame. The MAC address cannot be a multicast MAC address; it must be the MEP MAC destination address (DA).

Datapath processing of LBMs is supported with dot1ag and Y.1731 for the following MEPs:

  • SAP Up and Down MEPs

  • spoke SDP Up and Down MEPs

  • mesh SDP Up and Down MEPs (VPLS only)

For spoke or mesh SDP Up and Down MEPs, fastpath (datapath) LBM processing requires that both interfaces—the LBM receiver and the LBR transmitter—reside on the same adapter card. For example, if the 7705 SAR must perform a reroute operation and needs to move the next-hop interface to another adapter card (that is, LBMs are received on one card and LBRs are transmitted on another), the fastpath processing of LBMs is terminated and LBM processing continues via the CSM.

Continuity Check

The continuity check (CC) function is supported by 802.1ag and Y.1731 on the 7705 SAR. A Continuity Check Message (CCM) is a multicast frame that is generated by a MEP and sent to its remote MEPs in the same MA. The CCM does not require a reply message. To identify faults, the receiving MEP maintains a MEP database with the MAC addresses of the remote MEPs with which it expects to maintain connectivity checking. The MEP database can be provisioned manually. If there is no CCM from a monitored remote MEP in a preconfigured period, the local MEP raises an alarm.

The following CC capabilities are supported:

  • enable and disable CC for a MEP

  • automatically put local MEPs into the database when they are created

  • manually configure and delete the MEP entries in the CC MEP monitoring database. The only local provisioning required to identify a remote MEP is the remote MEP identifier (using the remote-mepid mep-id command).

  • CCM transmit interval: 10ms, 100ms, 1s, 10s, 1m, 10m (default: 10s)

  • transmit interval: 10ms, 100ms, 1s, 10s, 1m, 10m (default: 10s)

  • CCM declares a fault when it:

    • stops hearing from one of the remote MEPs for a period of 3.5 times the CC interval

    • hears from a MEP with a lower MD level

    • hears from a MEP that is not in the same MA

    • hears from a MEP that is in the same MA but is not in the configured MEP list

    • hears from a MEP that is in the same MA with the same MEP ID as the receiving MEP

    • recognizes that the CC interval of the remote MEP does not match the local configured CC interval

    • recognizes that the remote MEP declares a fault

      An alarm is raised and a trap is sent if the defect is greater than or equal to the configured low-priority-defect value.

  • CC must be enabled in order for RDI information to be carried in the CCM OAMPDU

Remote Defect Indication

The Ethernet Remote Defect Indication (ETH-RDI) function is used by a MEP to communicate to its peer MEPs that a defect condition has been encountered. Defect conditions such as signal failure and AIS may result in the transmission of frames with ETH-RDI information. ETH-RDI is used only when ETH-CC transmission is enabled and it is enabled automatically.

ETH-RDI has the following two applications:

  • single-ended fault management—the receiving MEP detects an RDI defect condition, which gets correlated with other defect conditions in this MEP and may become a fault cause. The absence of received ETH-RDI information in a single MEP indicates the absence of defects in the entire MEG.

  • contribution to far-end performance monitoring—the transmitting MEP reflects that there was a defect at the far end, which is used as an input to the performance monitoring process

A MEP that is in a defect condition transmits frames with ETH-RDI information. A MEP, upon receiving frames with ETH-RDI information, determines that its peer MEP has encountered a defect condition.

The specific configuration information required by a MEP to support the ETH-RDI function is as follows:

  • MEG level—the MEG level at which the MEP exists

  • ETH-RDI transmission period—application-dependent and is the same value as the ETH-CC transmission period

  • priority—the priority of frames containing ETH-RDI information and is the same value as the ETH-CC priority

The PDU used to carry ETH-RDI information is the CCM.

Alarm Indication Signal

The Ethernet Alarm Indication Signal (ETH-AIS) function is a Y.1731 CFM enhancement used to suppress alarms at the client (sub) layer following detection of defect conditions at the server (sub) layer.

Transmission of frames with ETH-AIS information can be enabled or disabled on a Y.1731 SAP MEP.

Frames with ETH-AIS information can be issued at the client MEG level by a MEP, including a server MEP, upon detecting the following conditions:

  • signal failure conditions in the case where ETH-CC is enabled

  • AIS condition in the case where ETH-CC is disabled

For a point-to-point Ethernet connection at the client (sub) layer, a client layer MEP can determine that the server (sub) layer entity providing connectivity to its peer MEP has encountered a defect condition upon receiving a frame with ETH-AIS information. Alarm suppression is simplified by the fact that a MEP is expected to suppress only those defect conditions associated with its peer MEP.

Only a MEP, including a server MEP, is configured to issue frames with ETH-AIS information. Upon detecting a defect condition, the MEP can immediately start transmitting periodic frames with ETH-AIS information at a configured client MEG level. A MEP continues to transmit periodic frames with ETH-AIS information until the defect condition is removed. Upon receiving a frame with ETH-AIS information from its server (sub) layer, a client (sub) layer MEP detects the AIS condition and suppresses alarms associated with all its peer MEPs. After the AIS condition is cleared, a MEP resumes alarm generation upon detecting defect conditions.

The following specific configuration information is required by a SAP MEP to support ETH-AIS:

  • client MEG level—the MEG level at which the most immediate client layer MEPs exist

  • ETH-AIS transmission period—the transmission period of frames with ETH-AIS information

  • priority—the priority of frames with ETH-AIS information

Ethernet Test

The Ethernet Test (ETH-Test) signal function is a Y.1731 CFM enhancement used to perform one-way, on-demand, in-service diagnostics tests, which include verifying frame loss and bit errors. ETH-Test is supported on Y.1731 SAP MEPs and facility MEPs on network interfaces.

Note: The out-of-service diagnostics test is not supported on the 7705 SAR.

When configured to perform such tests, a MEP inserts frames with ETH-Test information such as frame size and transmission patterns.

When an in-service ETH-Test function is performed, data traffic is not disrupted and the frames with ETH-Test information are transmitted.

To support ETH-Test, a Y.1731 SAP or facility MEP requires the following configuration information:

  • MEG level—the MEG level at which the MEP exists

  • unicast MAC address—the unicast MAC address of the peer MEP for which ETH-Test is intended

  • data—an optional element with which to configure data length and contents for the MEP. The contents can be a test pattern and an optional checksum.

    Examples of test patterns include all 0s or all 1s. At the transmitting MEP, this configuration information is required for a test signal generator that is associated with the MEP. At the receiving MEP, this configuration is required for a test signal detector that is associated with the MEP.

  • priority—the priority of frames with ETH-Test information

A MEP inserts frames with ETH-Test information toward a targeted peer MEP. The receiving MEP detects the frames with ETH-Test information and performs the requested measurements.

MEP Support (802.1ag and Y.1731)

The 7705 SAR supports the following MEPs for 802.1ag and Y.1731:

  • Up and Down MEPs on Ethernet (Epipe and VPLS) SAPs

  • Up and Down MEPs on Ethernet (Epipe and VPLS) spoke SDPs

  • Up and Down MEPs on mesh SDPs (VPLS only)

  • facility MEPs on network interfaces

802.1ag MEP Support on Ethernet SAPs

The 7705 SAR supports Up and Down MEPs on Ethernet SAPs. MEP on Ethernet Access shows that the 7705 SAR can terminate and respond to CFM messages received from connected devices, such as base stations, when port B is a Down MEP on a SAP. A CFM message coming from port A would be terminated on port B of the 7705 SAR. As well, port B on the 7705 SAR can generate and send a CFM message toward port A.

Figure 14. MEP on Ethernet Access

Down MEP at Ethernet SAP shows how a Down MEP on an Ethernet SAP may be used. In this example, an Ethernet network connects to an access Ethernet port on the 7705 SAR and there are multiple SAPs on that port (that is, multiple endpoints). Since CFM offers OAM capabilities on a per-service basis, which in this case means per SAP (or endpoint), each service can run CFM. If BSC end devices were directly connected to the 7705 SAR (and a VLAN was not used to separate services from each other), EFM would offer capabilities similar to CFM for Ethernet OAM.

In the example shown in Down MEP at Ethernet SAP, separate dot1ag instances initiated on the Wavence nodes can be used to ensure Ethernet layer connectivity on a per-base-station basis. All the traffic from these base stations is aggregated and switched to a single port on the 7705 SAR. Each base station is recognized through a different VLAN, where the VLANs are bound to different services. CFM with traffic in the Down MEP OAMPDU direction at the Ethernet SAP offers the flexibility to run OAM tests on a per-base-station basis.

Figure 15. Down MEP at Ethernet SAP

802.1ag and Y.1731 MEP Support on Ethernet Spoke SDPs and Mesh SDPs

The 7705 SAR supports Up and Down MEPs with 802.1ag and Y.1731 on Ethernet spoke SDP endpoints (Epipe and VPLS) and mesh SDP endpoints (VPLS only). Dot1ag Down MEPs on Spoke SDPs illustrates a dot1ag Down MEP on an Ethernet spoke SDP.

CFM messages can be generated and switched across an Ethernet PW. CFM messages that are received and have an MD that matches the value configured on the 7705 SAR are extracted and processed. Any received CFM messages with an MD level that does not match the configured value are not terminated and are switched transparently to the Ethernet SAP.

Up and Down MEPs on Ethernet spoke and mesh SDPs on the 7705 SAR support the following:

  • termination of the CFM messages destined for the MEP-ID of the 7705 SAR

  • termination of CFM messages at the user-configured domain only

  • discarding of OAMPDUs at a lower MD level than the configured one (an alarm message is raised)

  • transparent pass-through of upper-layer CFM messages

    • MD of the CFM messages that are higher than the one configured on the 7705 SAR

MIP functionality (that is, forwarding of CFM messages with the same MD level) is not supported.

Figure 16. Dot1ag Down MEPs on Spoke SDPs

In Dot1ag Down MEPs on Spoke SDPs, assuming that the MEP is enabled both on the 7750 SR and the 7705 SAR spoke SDP endpoints, the 7705 SAR can generate CFM messages and can terminate any received CFM messages that are destined for the 7705 SAR MEP-ID and have a matching configured domain. Any 7705 SAR-generated CFM packets would traverse the Ethernet PW and would be processed first by the 7750 SR node. The Ethernet PW running between the 7705 SAR and the 7750 SR generates a pipe-like connectivity; therefore, no intermediate Ethernet node can process the CFM messages. All the CFM messages are transported over Ethernet PWs, and PW termination only takes place on 7750 SR and 7705 SAR endpoints.

Y.1731 MEP Support on Ethernet SAPs

As shown in Y.1731 MEP Support on the 7705 SAR, the 7705 SAR supports Y.1731 Up and Down MEPs on Ethernet SAPs that are bound to an Ethernet PW service.

Y.1731 MEP Support on the 7705 SAR also shows an 802.1ag Down MEP on an Ethernet spoke SDP in order to illustrate that when performing CFM tests on the 7705 SAR, a Y.1731 Up MEP on an Ethernet SAP should be used instead of an 802.1ag Down MEP on an Ethernet spoke or mesh SDP. Using a Y.1731 SAP Up MEP means that CFM packets verify the switching fabric and SAP status before the packet is processed, because the SAP is on the access side of the 7705 SAR whereas a spoke or mesh SDP is on the network side. If a spoke or mesh SDP Down MEP is used, packets are terminated and extracted on the network side without being switched through the switching fabric.

Figure 17. Y.1731 MEP Support on the 7705 SAR

Priority Mapping (802.1ag and Y.1731)

Operators often run OAM tests over a single, specific forwarding class (FC). For example, an operator may be mapping OAM traffic to FC2 (AF – Assured Forwarding) and, in order to examine the delay, jitter, or loss qualities of the OAM traffic, would need to run OAM tests using FC2. To provide operators with the ability to control which FC the OAM packets will follow, the priority priority command is included in several OAM test commands.

When the 7705 SAR generates an Ethernet OAM frame, it uses the priority as per the user’s configuration of the priority keyword and then sends the frame through the datapath. Therefore, the OAM frame follows the entire datapath and receives the same treatment as any other user frame before it is switched over the port.

For example, a CCM frame generated by a SAP Up MEP with a priority value of 7 will receive the following treatment.

  • First, the CCM frame is classified as per the access ingress and QoS policy settings. For example, the CCM frame can be mapped to the BE forwarding class if the assigned QoS policy has its priority 7 mapped to BE.

  • Then, the OAM packet is mapped to the associated queue (the queue hosting the BE forwarding class) and follows ingress scheduling like any other datapath frame.

  • Next, the CCM frame is switched through the fabric and reclassified to the network egress queues, as per the assigned QoS policy classifiers.

  • Finally, the CCM frame is scheduled again, as per the queue type and profile state of the queue.

This implementation replicates the user experience since the OAM packet follows the same path as the data packets.

Priority Mapping for SAP Up MEPs

For Up MEPs on a SAP, priority mapping operates as described in the following list, which indicates how the messages or replies generated on ingress have their FC and VLAN tag priority set.

The resulting frames (CCM, LMM, DMM, 1DM, LBM, LMR, DMR, or LBR) are inserted in the access ingress datapath and are processed in the same way as any other frame. That is, they are classified based on the SAP ingress policy.

  • Continuity Check Messages (CCMs) generated on ingress are based on the setting of the ccm-ltm-prio command for the MEP (that is, the VLAN tag priority is set according to the ccm-ltm-prio command for the MEP).

  • Loss Measurement Messages (LMMs), two-way Delay Measurement Messages (DMMs), one-way Delay Measurement Messages (1DMs), and Loopback Messages (LBMs) generated on ingress are based on the priority specified during the LMM, DMM, 1DM, or LBM test (that is, the VLAN tag priority is set according to the priority specified during the test).

  • Loss Measurement Replies (LMRs), two-way Delay Measurement Replies (DMRs), and Loopback Replies (LBRs) generated on ingress keep the VLAN tag priority of their corresponding LMM or DMM frame.

FC and VLAN Priority Mappings for Up and Down MEPs as per Frame Type summarizes the 7705 SAR FC and VLAN priority mappings for SAP Up and Down MEPs based on the frame type.

Table 10. FC and VLAN Priority Mappings for Up and Down MEPs as per Frame Type

MEP Type

Frame Type (Tx)

FC

VLAN priority

SAP Up MEP

CCM

derived from vlan-prio after classification

ccm-ltm-prio

LMM, DMM, 1DM, LBM

derived from vlan-prio after classification

user-specified

LMR, DMR, LBR

derived from vlan-prio after classification

preserve incoming query priority

SAP Down MEP

CCM

ccm-ltm-prio

ccm-ltm-prio

LMM, DMM, 1DM, LBM

user-specified

user-specified

LMR, DMR, LBR

ccm-ltm-prio

incoming tag priority

Priority Mapping for SAP Down MEPs

For SAP Down MEPs, priority mapping operates as described in the following list, which indicates how the messages or replies generated on egress have their FC and VLAN tag priority set.

  • CCMs generated on egress are based on ccm-ltm-prio of the MEP (that is, FC and VLAN tag priority are set according to the ccm-ltm-prio of the MEP).

  • LMM, DMM and 1DM generated on egress are based on the priority specified during the test (that is, FC and VLAN tag priority are set according to the priority specified during the test).

  • LMR, DMR, and LBR generated on egress use the ccm-ltm-prio of the MEP as FC. The VLAN tag priority is not replaced (that is, the VLAN tag priority of LMM and DMM are kept).

G.8032 Ethernet Ring Protection Switching

This section contains the following topics:

The 7705 SAR supports Ethernet ring protection switching in accordance with ITU-T G.8032 to achieve resiliency for Ethernet Layer 2 networks. A G.8032 Ethernet ring is built on Ethernet OAM and is also referred to as Ring Automatic Protection Switching (RAPS).

Ethernet rings are supported on VPLS SAPs. VPLS services supporting Ethernet rings can connect to other rings and Ethernet services using VPLS and r-VPLS SAPs. Ethernet rings provide rings for core network or access network resiliency. A single point of interconnection to other services is supported. The Ethernet-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 combined service protection ensures that higher layers are isolated from failures because there will only be a RAPS switchover when the lower layer cannot recover.

Rings are preferred in data networks where the native connectivity is laid out in a ring or where there is a requirement for simple resilient LAN services. Due to the symmetry and the simple topology, rings are considered a good solution for access and core networks where resilient LANS are required. The 7705 SAR implementation can be used for interconnecting access rings and to provide traffic engineered backbone rings.

Even though 7705 SAR nodes are often connected via IP/MPLS links to each other or to higher hierarchies, the first level of connected aggregation nodes can significantly benefit from G.8032 protection switching. Ethernet Protection Switching shows a common example where standalone microwave nodes are deployed in a ring that are connected to a 7705 SAR node acting as the head-end of the ring. Providing G.8032 Ethernet ring protection switching would provide significantly better reconvergence times in the ring and ensure minimal service disruption in case of failure.

Figure 18. Ethernet Protection Switching

Ethernet rings use one VLAN ID per control per ring instance and use one or more VIDs for data instances per control instance. A dedicated control VLAN (ERP VLAN) is used to run the protocol on the control VLAN ID. 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 7705 SAR supports dot1q and qinq encapsulation for data ring instances. The control channel supports dot1q and qinq encapsulation. The control channel can support dot1q while the data channels use qinq if the global new-qinq-untagged- sap command is enabled.

Overview of G.8032 Operation

RAPS messages that carry the G.8032 protocol are sent on a dedicated protocol VLAN called the Ethernet Ring Protection (ERP) instance. Revertive and non-revertive behaviors are supported. In revertive mode, the G.8032 protocol ensures that one Ring Protection Link (RPL) owner blocks the RPL. RAPS messages are periodically sent around the ring 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.

Y.1731 Ethernet OAM CC is the basis of the RAPS messages. Nodes in the ring typically us Y.1731 CC messages to monitor the health of each link in the ring in both directions. CC messages are not mandatory. Other link layer mechanisms could be used, for example, Loss of Signal (LOS) for instances 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. After a ring node in the ring learns that another link is blocked, the node unblocks its blocked link possibly causing an FDB flush of all links in the ring for the affected service VLANs controlled by the ring control instance. This results in unblocking all links except one so that the ring is in the normal, or idle, state. In revertive mode, the link that is blocked when all other links are operable after the revert time has expired becomes the RPL. In non-revertive mode the RPL is no different than other ring links. Revertive mode offers predictability, especially when there are multiple ring instances and the operator can control which links are blocked on each instance. When there is a topology change that affects reachability, the nodes may flush the FDB and MAC learning occurs for the affected service VLANs, which allows packet forwarding to continue. G.8032 Ring in the Idle State depicts this operational state.

Figure 19. G.8032 Ring in the Idle State

When a ring failure occurs, any node that detects the failure (by using Y.1731 OAM CC monitoring) sends RAPS message in both directions. After receiving a failure notification, the nodes at both ends of the failed link block forwarding to the failed link to prevent it from becoming active.

When a ring failure occurs in revertive mode, the RPL owner unblocks the previously blocked RPL and triggers an FDB flush for all nodes for the affected service instances. The ring is now in the protecting state and full ring connectivity is restored. MAC learning occurs, which allows Layer 2 packet forwarding on the ring. G.8032 Ring in the Protecting State depicts a G.8032 ring in the protecting state.

Figure 20. G.8032 Ring in the Protecting State

After the failed link recovers, the nodes that blocked the link send RAPS messages indicating no failure. This triggers the RPL owner to block the RPL link and indicate the blocked link in its own RAPS message. When the nodes at the recovered link receive the RPL RAPS message, they unblock the specified link, restore connectivity, and all nodes in the ring perform an FBD flush. MAC learning takes place and the ring returns to the normal, or idle, state.

Each path uses Y.1731 Maintenance Entity Groups (MEGs) and Maintenance Endpoints (MEPs) to exchange RAPS-specific information to co-ordinate switchovers. As well Y.1731 MEGs and MEPs optionally use fast Continuity Check Messages (CCM), which provide an inherent fault detection mechanism as part of the protocol. When a ring path failure is detected, the protection links are activated. During a failure, reconvergence times depend on the failure detection mechanisms being used. For Y.1731, the CCM transmit interval determines the response time. The router supports message timers as low as 10 ms, providing restoration times comparable to SONET/SDH. Alternatively, 802.3ah (Ethernet in the First Mile) or simple LOS can act as a trigger for a protection switch where appropriate. Where nodes are directly connected there is no need to use Ethernet CC messaging for liveness detection.

G.8032 supports multiple data channels (VLAN IDs) or instances per ring control instance (RAPS tag). G.8032 also supports multiple control instances such that each instance can support RPLs on different links, providing load balancing capability. However, once services have been assigned to one instance the rest of the services that need to be interconnected to them must be on the same instance. In other words, each data instance is a separate data VLAN on the same physical topology. If there is a single link or node failure in the ring, G.8032 protocols are capable of restoring traffic between all remaining nodes in these data instances.

Ethernet RAPS can be configured on any port configured for access mode by using dot1q or qinq encapsulation, enabling support for Ethernet RAPS protected services on the service edge toward the customer site or within the Ethernet backbone.

The Ethernet ring is built from a VPLS service on each node with VPLS SAPs that provide ring paths with SAPs. As a result, most of the VPLS SAP features are also available on Ethernet rings resulting in a feature-rich ring service.

The control tag defined under each Ethernet 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 CCMs exchanged on that segment or will receive a fault indication from the link layer OAM module. CCMs are optional but MEPs are always configured to provide G.8032 control. The forwarding of CCMs and G.8032 RAPS messages continues in the control VPLS even if the service or its SAPs are administratively shut down. The Ethernet ring instance can be shut down to stop the operation of the ring on a node.

For fault detection using CCMs, three CC messages and a configurable hold-off timer must be missed for a fault to be declared on the associated path. The hold-off timer is required in order to support an additional 50 ms resiliency mechanism in the optical layer. After receiving the fault indication, the protection module declares the associated ring link down and the G.8032 state machine sends the appropriate messages to open the RPL and flush the learned addresses.

Flushing is triggered by the G.8032 state machine and the router implementation allows flooding of traffic during the flushing interval to expedite traffic recovery.

Ring Example illustrates a resilient Ring Service. In the example, a ring (solid line) with that usage dot1q VLAN ID 100 carries service VID 500. The RPL for the ring is between A and B, where B is the RPL owner. Also illustrated is a QinQ service on the (dotted line) ring that uses dot1q VLAN ID 600 for the ring to connect service VLAN 100.50. The two rings have RPLs on different nodes, which allows a form of load balancing.

Ring Example illustrates that service encapsulations and ring encapsulation can be mixed in various combinations. Neither of the rings is a closed loop. When any one node or link fails, a ring can restore connectivity to all remaining nodes within the 50 ms transfer time (the signaling time after detection).

Figure 21. Ring Example
Example:
configure 
    	eth-ring 1
            		description "Ethernet Ring on Node B"
            		revert-time 100
            		guard-time 5
            		ccm-hold-time down 100 up 200
            		rpl-node owner
            		path a 1/6/1 raps-tag 100 
            # Control Channel Tag 100
                			description "To A ring link"
                			rpl-end
                			eth-cfm
                    				mep 1 domain 1 association 1 
                        					control-mep
                        					no shutdown
                    				exit
                			exit
                			no shutdown 
            		exit
            		path b 1/6/2 raps-tag 100 # Control Channel Tag 100
                			description "to D Ring Link"
                			eth-cfm
                    				mep 1 domain 1 association 1 
                        					control-mep
                        					no shutdown
                    				exit
                			exit
                			no shutdown
            		exit
            		no shutdown
        	exit
        	service
            		vpls 10 customer 1 create # Ring APS SAPs
                			description "Ring Control VLAN ID 100"
                			sap 1/6/1:100 eth-ring 1 create
                			# TAG for the Control Path a
                    				no shutdown
                			exit
                			sap 1/6/2:100 eth-ring 1 create
                			# TAG for the Control Path b
                    				no shutdown
                			exit
            		no shutdown
            		vpls 40 customer 1 create 
                			description "Data service over Ethernet Ring 1 VLAN ID 500"
                			sap 1/1/1:100 create 
                # Traffic from uW node
                    				no shutdown
                			exit
                			sap 1/6/1:500 eth-ring 1 create
                			# TAG for the Data Channel Path a
                    				no shutdown
                			exit
                			sap 1/6/2:500 eth-ring 1 create
                			# TAG for the Data Channel Path b
                    				no shutdown
                			exit
            		no shutdown
            		exit

Ethernet Ring Sub-Rings

Ethernet sub-rings offer a dual redundancy with interconnected rings. The router supports sub-rings connected to major rings and a sub-ring connected to an LDP-based VPLS for access ring support in VPLS networks. G.8032 Sub-Ring and Sub-Ring Configuration Example illustrates 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. The sub-ring (ERP2) relies on the major ring (ERP1) as part of its protection for traffic from nodes C and D, which are configured as interconnection nodes.

Figure 22. 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 router. When major rings change topology, the flush is propagated around the major ring but 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 usually need to be propagated to the other ring or network. Sub-rings offer the same capabilities as major rings in terms of control and data so that all link resources may be used.

Virtual and Non-Virtual Channel

The 7705 SAR supports sub-ring control communication using either a virtual channel or non-virtual channel. In virtual channel mode, a dedicated VLAN ID, other than the major ring RAPS control channel, is configured as a data instance on the major ring. This allows the sub-ring control messages and state machine logic to function similar to a major ring. In non-virtual channel mode, the sub-ring is only connected by the RAPS control channels on the sub-ring itself. This mode offers slightly less redundancy in the RAPS messaging than the virtual channel mode because sub-ring RAPS messages are not propagated across the major ring. When a non-virtual link is configured, the protocol allows RPL messages over the sub-ring blocked link. Sub-Ring Configuration Example shows a sub-ring configuration using virtual and non-virtual channels.

Figure 23. Sub-Ring Configuration Example

Sub-ring configuration is similar to major ring configuration and consists of three parts:

  • Ethernet ring instance configuration

  • control VPLS configuration

  • data VPLS configuration (data instance or data channel)

The Ethernet ring configuration of a sub-ring is tied to a major ring and only one path is allowed. A split horizon group is mandatory to ensure that sub-ring control messages from the major ring are only passed to the sub-ring control.

As with a major ring, CCMs and RAPS messages continue to be forwarded in the control VPLS even if the service or its SAPs are administratively shut down. The Ethernet ring instance can be shut down to stop the operation of the ring on a node.

The data VPLS can be configured on the major ring and shares the same VLAN ID (SAP encapsulation) on both the major ring and the sub-ring to keep data on the same VLAN ID everywhere. See the configuration example shown below. Like other services in the router, the encapsulation VLAN ID is controlled by SAP configuration and the association to the controlling ring is by the Ethernet ring ID.

The following CLI output is an example of a sub-ring configuration on Node C shown in Sub-Ring Configuration Example:

eth-ring 2
        description "Ethernet Sub Ring on Ring 1"
        sub-ring virtual-link // Using a virtual link
            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 VLAN ID 100
            eth-cfm
                mep 9 domain 1 association 4
                    ccm-enable
                    control-mep
                    no shutdown
                exit
            exit
            no shutdown
        exit
        no shutdown
    exit

If the sub-ring had been configured as a non-virtual-link, the sub-ring configuration above and on all the other sub-ring nodes for this sub-ring would instead be:

        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 VLAN ID 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 VLAN ID 11 for Ring 1"
      stp shutdown
      sap 1/1/1:11 eth-ring 1 create // VLAN ID 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 VLAN ID to be configured.

  vpls 100 customer 1 create
      description "Control VLAN ID 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

The 7705 SAR supports a special configuration of the non-virtual link sub-ring that can be homed to a VPLS service as illustrated in Sub-Ring Homed to VPLS. This is an economical way to have a redundant ring connection to a VPLS service. This is currently supported only for dot1q and qinq sub-rings and only on LDP-based VPLS. The primary application for this is access rings that require resiliency. This example in Sub-Ring Homed to VPLS shows a sub-ring at an interconnection node without a virtual channel and interconnected to a VPLS. A VPLS service 1 is used to terminate the ring control. The Ethernet ring data SAP appears in the associated LDP-based VPLS service 5.

Figure 24. Sub-Ring Homed to VPLS

The following CLI output is an example of a sub-ring configuration for VPLS PE1 of Multi-Ring Hierarchy:

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

# Configuration for the ring control interconnection termination:
  
  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 LDP based 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

Ethernet rings and sub-rings offer a way to build a scalable and resilient Ethernet transport network. Multi-Ring Hierarchy illustrates a hierarchical ring network where dual-homed services are connected to an Ethernet ring network.

Figure 25. Multi-Ring Hierarchy

Major rings are connected by sub-rings to the top level major ring. These sub-rings require a virtual channel and will not work with non-virtual channels. Ring flushing is contained to major rings or in the case of a sub-ring link failure or node failure, to the sub-ring and any directly attached major rings.

LAG Support

Ethernet rings support LAG on Ethernet ring SAPS. However, using LAG impacts the resiliency response time. In many cases, operators may achieve better resiliency response time and QoS by using multiple ring instances, each on a single link, instead of LAG on Ethernet rings. If a response time of less than 100 ms is not required, LAG is an acceptable option for Ethernet rings.

OAM Considerations

Ethernet CFM is enabled by configuring MEPs on each individual path under an Ethernet ring. Only down MEPs can be configured on each path. CCM sessions can also be enabled to monitor the liveness of the path using an interval of 10 ms or 100 ms. Different CCM intervals can be supported on path A and path B in an Ethernet ring. CFM is optional if the node supports LOS, which is controlled by configuring no-ccm-enable.

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

When an Ethernet ring is configured on two ports located on different cards, the SAP queues and virtual schedulers are created with the actual parameters on each card.

Ethernet ring CC messages that are transmitted over the SAP queues using the default egress QoS policy use network class (NC) as a forwarding class. If user traffic is assigned to the NC forwarding class, it will compete for bandwidth resources with the Ethernet CCMs and cause congested queues. This congestion can result in CCM loss that could lead to unnecessary switching of the Ethernet ring. To avoid potential congestion, configure different QoS policies that will control the amount of traffic assigned into the corresponding queue.

Support Service and Solution Combinations

Ethernet rings are supported on VPLS and r-VPLS instances. The following considerations apply.

  • Only ports in access or hybrid mode can be configured as Ethernet ring paths. The ring ports can be located on the same or different media adapter cards.

  • Dot1q and qinq ports are supported as Ethernet ring path members.

  • A mix of regular and multiple Ethernet ring SAPs and pseudowires can be configured in the same services.

QinQ Support

Overview of QinQ

On the 7705 SAR, QinQ (also referred to as VLAN stacking) is based on the IEEE 802.1ad specification. QinQ allows a service provider to use a single VLAN for customers needing multiple VLANs by adding a second VLAN tag to an Ethernet frame, as shown in QinQ Frame. QinQ encapsulation can be thought of as a dot1q within a dot1q encapsulation.

QinQ operates from end-to-end by receiving customer frames on an ingress SAP, transporting the frames over a service tunnel, and receiving them at the far-end router, where they are unpacked and sent through the egress SAP to the customer.

Figure 26. QinQ Frame

On the 7705 SAR, QinQ ports and QinQ SAPs offer the same feature set as dot1q ports and dot1q SAPs for the following features:

  • OAM

  • redundancy

  • synchronization

  • QoS

  • card and node limits

QinQ is supported on the following service SAPs (including SAP-to-SAP configurations):

  • VLL services (Epipe and Ipipe)

  • VPLS

  • VPRN

  • IES

QinQ is supported on the following adapter cards, modules, and nodes:

  • 6-port Ethernet 10Gbps Adapter card

  • 8-port Gigabit Ethernet Adapter card

  • 10-port 1GigE/1-port 10GigE X-Adapter card (10-port 1GigE mode)

  • Packet Microwave Adapter card

  • 4-port SAR-H Fast Ethernet module

  • 6-port SAR-M Ethernet module

  • 7705 SAR-M

  • 7705 SAR-A

  • 7705 SAR-Ax

  • 7705 SAR-Wx (Ethernet ports)

  • 7705 SAR-H

  • 7705 SAR-Hc

  • 7705 SAR-X

QinQ Tagging Example shows an example of QinQ tagging, where three customer sites each use the same service provider PE router to transport multiple VLANs across an MPLS network. Customer 1 sends an Ethernet frame without a VLAN tag (null encapsulation) and the provider uses MPLS label 25. Customer 2 sends dot1q frames (VLAN ID 20) and the provider uses MPLS label 35. Lastly, customer 3 sends a qinq frame (VLAN ID 10:300) and the provider uses MPLS label 45.

For details on VLAN translation in an Ethernet frame from ingress SAP to egress SAP, see Raw and Tagged Modes.

Figure 27. QinQ Tagging Example

QinQ Support with Forced C-Tag Forwarding (VPLS only)

For VPLS, force-c-vlan-forwarding can be user-configured as enabled or disabled. When force-c-vlan-forwarding is enabled at the ingress and egress SAPs, the VLAN tag transmitted at the far-end egress SAP is the same as the VLAN tag received at the near-end ingress SAP.

The following examples illustrate the QinQ implementation. Example 1 is a general example. Examples 2 and 3 are examples where the 7705 SAR parses a single frame that has three VLAN tags. For examples 2 and 3, the innermost VLAN Ethertype is always set to 0x8100.

Example 1: General QinQ Implementation

When a service has multiple SAPs configured that can match an incoming frame, the SAP with the most explicit match transmits the frame. For this example, assume that the following SAPs are configured on a port and that the port is in QinQ mode:

  • SAP_1 identifier is port-id:vlan-x.vlan-y

  • SAP_2 identifier is port-id:vlan-x.*

  • SAP_3 identifier is port-id:*.*

For an incoming frame with VLAN tags vlan-x.vlan-y, SAP_1 processes the frame because it is the most explicit match. Although SAP_2 and SAP_3 also match the frame, the most explicit SAP prevails.

Example 2: QinQ using VPLS with Ethernet SAPs

In this example, assume that the 7705 SAR parses a single frame that has three VLAN tags (innermost VLAN Ethertype is always set to 0x8100). This may occur in the scenario shown in QinQ Using VPLS Ethernet SAPs, where VPLS QinQ SAPs with force-c-vlan-forwarding enabled connect Customer 1 and Customer 2 and preserve the ingress VLAN tag.

Figure 28. QinQ Using VPLS Ethernet SAPs

In QinQ Using VPLS Ethernet SAPs, the following events occur.

  • At Node_1, an ingress QinQ SAP with force-c-vlan-forwarding enabled receives a frame and ensures that the bottom (inner) tag is preserved. The frame is then sent to an egress qinq-encapsulated SAP, where the top (outer) tag is swapped and an additional (third) tag is pushed on top.

  • At Node_2, the frame with three tags is received on a qinq-encapsulated SAP. The frame is then sent to an egress QinQ SAP with force-c-vlan-forwarding enabled, where the egress qinq-encapsulation SAP:

    • removes the first (top) tag

    • replaces the second (middle) tag

    • replaces only the Ethertype of the third (bottom/innermost) tag (that is, the VLAN ID is not replaced)

Example 3: QinQ Using VPLS with ATM SAPs

A second example of triple-tag behavior is shown in QinQ Using VPLS ATM SAPs, where customers are connected using ATM SAPs with subscriber-vlan enabled.

Figure 29. QinQ Using VPLS ATM SAPs

In this example, the ATM SAP with subscriber-vlan enabled pushes a tag on the frame at ingress. The frame is then sent toward a qinq-encapsulated SAP on egress, which pushes two more tags onto the frame. At the far end, the frame (with three tags) is received on a qinq-encapsulated SAP and sent toward the egress ATM SAP with subscriber-vlan enabled. In this case, the egress ATM-encapsulated SAP must be able to remove the three tags.

QinQ Support on Ethernet Ports

This section contains the following topics:

QinQ requires that the encap-type for the associated port be set for qinq, and that the sap-id include two Q-tags (VLAN IDs). An ingress QinQ SAP can be configured so that dot1p bits for packet QoS classification can come from the top or the bottom Q-tag. At egress, if dot1p re-marking is configured, both Q-tags are re-marked. However, you can use qinq-mark-top-only to re-mark only the top Q-tag.

Special QinQ SAP Identifiers

Special QinQ SAP Identifiers describes the special SAP identifiers used on the 7705 SAR. In Special QinQ SAP Identifiers, a qtag value represents a VLAN ID. The * (asterisk) represents a reserved VLAN that is used to carry traffic from any unused VLAN on the port. An unused VLAN is a VLAN that is not explicitly defined on the port.

Table 11. Special QinQ SAP Identifiers

QinQ SAP Type

SAP Identifier

Example

Notes

Explicit (specified)

port-id:qtag1.qtag2 1

1/1/1:20.2000

qtag1 and qtag2 range: 0 to 4094, and *

Null

port-id

port-id:0

port-id:0.*

port-id:qtag1.0 2

1/1/1

1/1/1:0

1/1/1:0.*

No suffix means no VLANs

0 suffix means SAP 0

0.* suffix means SAP 0 and any unused VLAN on the port

Default

port-id:*

port-id:*.*

port-id:qtag1.*

1/1/1:*

1/1/1:*.*

1/1/1:40.*

*.* means any unused VLAN on the port 3

Notes:

  1. qtag1 is the top (outer) tag; qtag2 is the bottom (inner) tag.

  2. This configuration becomes available when the new-qinq-untagged-sap command is enabled.

  3. The behavior of the *.* SAP on the 7705 SAR is different from the *.* SAP behavior on the 7750 SR. On the 7750 SR, *.* represents a capture SAP.

Note: The following default SAPs are not supported on the 7705 SAR:
  • port-id:*.0

  • port-id:*.vlan-y

The following list describes how the SAP types in Special QinQ SAP Identifiers process frames. Packet breakdowns are described in Raw and Tagged Modes.

  • default SAP (port-id:qtag1.*)

    • receives all frames with an explicit outer tag value of qtag1, regardless of the inner tag

    • the outer tag is stripped and the inner tag is passed transparently

    • example: SAP 1/1/1:10.* only matches a top Q tag of VLAN 10. The SAP may have any bottom tag or no bottom tag at all.

  • null SAP (port-id:0.*)

    • receives all untagged frames and/or any frames with a VLAN tag of 0

    • example: SAP 1/1/1:0.* allows any untagged frames and/or frames with an outer tag of ‟0” only

      If the outer tag is 10, then the frame is dropped. If the outer tag is 0 and the inner tag is any valid VLAN ID, then the frame is not dropped.

  • null inner SAP (port-id:qtag1.0)

    • receives all frames with explicit outer tag value qtag1, and may have an inner tag of 0 or no inner tag at all

    • example: SAP 1/1/1:10.0 or SAP 1/1/1:10 will only match ‟10” as the outer tag, and may have a bottom tag of 0 or no bottom tag at all. The SAP 1/1/1:1/10 will be dropped because its outer tag is not ‟10”.

  • invalid SAPs (not supported) (port-id:*.qtag2 and port-id:*.0)

QinQ Dot1p Match Behavior

Since a qinq-encapsulated packet has top and bottom Q-tags, you can specify which qtag position provides the dot1p bits (P-bits) when QoS evaluates the P-bits in an ingress packet for a classification match. This is done with the sap>ingress>match-qinq-dot1p command. The default setting is to use the P-bits from the inner (bottom) Q-tag, or if the ingress packet has no Q-tags or has null encapsulation, then no match filtering is done.

QinQ Top-Only Mark Option

By default, if dot1p re-marking is configured at SAP egress on a QinQ SAP, the dot1p bits for both the top and bottom tags are re-marked. However, re-marking can be configured such that only the top Q-tag P-bits get remarked by enabling the sap>egress>qinq-mark-top-only command. The DEI bit is ignored.

Maximum Number of VLAN Tags

The maximum number of VLAN tags allowed in a packet depends on whether the service requires Layer 3 packet parsing (for example, to access to the IP header), as follows.

  • For services that do not require access to the Layer 3 IP header, such as Ethernet PWs and VPLS, there is no limit on the number of VLAN tags in the packet. Any packet with any number of VLAN tags is accepted.

  • For services that require access to the Layer 3 IP header, such as IP PWs, IES, and VPRN, there is a limit of three or fewer VLAN tags. When a packet is received that has four VLAN tags, the data following the third VLAN tag is considered as an IP packet. As a result, packets with four VLAN tags will be dropped by these services due to the inability to decode the IP header.

QinQ Configuration Overview

The basic steps to configure QinQ are as follows.

  1. Configure the port encap-type for qinq and (optionally) set the Ethertype (qinq-etype).

  2. Create one or more SAPs for the service.

  3. Configure the SAP ingress dot1p re-marking behavior (match the top or bottom tag).

  4. Enable the SAP egress qinq-mark-top-only command.

  5. Configure the spoke SDP vc-type (ether or vlan).

Raw Socket IP Transport Service

Serial data transport using raw sockets over IP transport services is a method of transporting serial data, in character form, over an IP network using Layer 3-based services. This feature can help transport Supervisory Control and Data Acquisition (SCADA) data from Remote Terminal Units (RTUs) to Front-End Processors (FEPs), or SCADA masters.

The functionality provided by the IP transport service feature for serial raw sockets is summarized as follows:

  • IP transport local host (server) function, to listen to and open raw socket sessions from remote hosts

  • IP transport remote host (client) function, to initiate and open new raw socket sessions to remote hosts

  • both local host and remote host functions support for either TCP or UDP IP transport services

  • IP transport over an IES or VPRN service

  • enhanced QoS and queuing of sessions to ensure that collisions between sessions do not cause serial data to impact RTUs and end-user equipment

IP Transport Service illustrates a detailed view of the local host (server) and remote host (client) functionality that enables multiple communication streams to and from a serial port using raw socket IP transport.

The figure shows a three-node network: a 7705 SAR-H or 7705 SAR-Hc (left), a 7705 SAR-8 Shelf V2 or 7705 SAR-18 (top right) and a 7705 SAR-H/7705 SAR-Hc node, 7705 SAR-8 Shelf V2/7705 SAR-18 node, or 7750 SR/VSR node (bottom right). There are two devices, RTU (1) and RTU (2) connected to the serial ports on the 7705 SAR-H/7705 SAR-Hc. FEP server [A] can reach the RTUs via the socket sessions that originate from the 12-port Serial Data Interface card on the 7705 SAR-8 Shelf V2/7705 SAR-18 node. The bottom-right 7705 SAR or 7750 SR/VSR node is connected to FEP server [B] directly using Ethernet. This FEP server reaches the RTUs via a Layer 3 IP/MPLS service where raw socket sessions are processed directly on the FEP servers.

Through local host and remote host configurations on the 7705 SAR-H/7705 SAR-Hc or 7705 SAR-8 Shelf V2/7705 SAR-18, serial raw socket IP transport sessions are established to carry serial data over a wireless IP/MPLS network. The source and destination IP addresses and port numbers for these sessions are derived directly from the local/remote host configurations associated with each serial port or master head-end server.

Figure 30. IP Transport Service

The 7705 SAR-H/7705 SAR-Hc supports the ability to configure a raw socket IP transport interface for each serial port. This allows the raw socket IP transport to receive TCP or UDP session packets from multiple remote hosts when operating as a local host (server), or to create new multiple sessions to remote hosts to send and receive serial data when operating as a client.

There are two main configurations required for a serial raw socket IP transport service to be operational and to support the sending and receiving of serial data:

  • port-level configuration

    This includes configuring rudimentary serial link parameters such as baud rate, start/stop values, and bits. Socket-level configuration is also required, such as configuring end-of-packet checking parameters (idle-time, length, special character) and the inter-sessions delay for transmitting sessions data out the serial link. For information about the required port-level configuration, see the 7705 SAR Interface Configuration Guide, Configuration Command Reference chapter, ‟Serial Commands”.

  • IP transport service-level configuration

    This includes creating an IP transport subservice to associate the serial port within a Layer 3 IES/VPRN service, so that TCP/UDP encapsulated serial data can be routed within the corresponding Layer 3 service. The IP transport subservice ID is modeled and created in the same way that the SAP IDs are created under the same service types. IP transport configuration includes configuring IP transport local host items and remote host items, such as setting TCP timers and sessions controls. See IES Command Reference and VPRN Services Command Reference for the required commands.

The 7705 SAR-H/7705 SAR-Hc supports the configuration of a raw socket IP transport service for each serial port. This allows each serial port’s local host to listen to and open raw socket sessions from remote hosts that need to communicate over the serial port, and for each serial port’s local host to initiate and open raw socket sessions to remote hosts when serial data needs to be sent to those remote hosts. The local and remote host functions support TCP or UDP sessions (but not both concurrently) over the IES/VPRN service.

The serial data is received as characters that represent bytes in a packet. These bytes are packetized into Layer 3 TCP/UDP packets that are then transported or forwarded across the IP/MPLS network using the node’s Layer 3 IES/VPRN service constructs for routing. TCP/UDP Packet Transport Over IP/MPLS illustrates how serial data is encapsulated into TCP/UDP packets and transported over IP/MPLS.

Figure 31. TCP/UDP Packet Transport Over IP/MPLS

For raw socket packets to be routed within an IES/VPRN service, an IP transport subservice must be configured within an IES/VPRN context. The IP transport subservice context is where users configure local host and remote host information, such as IP addresses and ports for establishing TCP/UDP sessions, and other per-session parameters. TCP/UDP encapsulated serial data is routed within the corresponding Layer 3 IES/VPRN service. IES/VPRN IP Transport Service illustrates this concept.

Figure 32. IES/VPRN IP Transport Service

To create an IP transport subservice, the ip-transport command is used with the corresponding serial port as the ipt-id to bind the serial port SAP to the IP transport subservice. After the IP transport service is created, local host and remote host configurations can proceed. A local host must be configured before remote hosts can be configured.

Each local host uses a local address (from a loopback or local interface configured under the IES/VPRN service context) as the local host IP address of the IP transport subservice associated with the serial port. The local host IP address is the source IP address in the raw socket packets leaving the node within the IES/VPRN service. The local host is used to terminate TCP/UDP sessions from remote hosts. The local host can select either the TCP or UDP protocol for raw socket sessions but not both concurrently.

Multiple remote hosts can be configured under the IP transport subservice associated with the serial port so that each remote host receives the serial data that is received on the serial port. Each remote host has its own remote destination IP address and port value for establishing sessions. The configured remote hosts use the TCP or UDP protocol configured for the IP transport subservice.

Note: It is not necessary to configure remote hosts when the IP transport service is not originating sessions. If sessions are only established toward the IP transport local host (for example, remote servers polling the local host), the remote host configuration is not necessary. Remote host configurations may still be desirable when using the filter-unknown-host command.

IP transport processing of TCP/UDP packets occurs on the CSM of the 7705 SAR-H/7705 SAR-Hc. Filters configured for protecting the CSM must take into account the raw socket IP transport packets and ensure that the filter is not blocking associated IP transport sessions. For example, operators must ensure that interface IP addresses and ports configured on the node are not blocked and that remote host IP/port combinations are not blocked.

For IES/VPRN IP transport services, all tunnel types supported by the IES/VPRN service are also supported for the IP transport service. This includes all types of MPLS tunnels (such as RSVP-TE, LDP, auto-bind, static LSP) and GRE tunnels.

Note: IP transport-to-IP transport raw socket data on the same node is not supported. If serial-to-serial communication is needed on the same node, customers must use Cpipes.

The 7705 SAR supports the concurrent operation of raw sockets and Cpipes on the 12-port Serial Data Interface card, version 2 and version 3. See Raw Socket and Cpipe Support on the 7705 SAR.

Figure 33. Raw Socket and Cpipe Support on the 7705 SAR

Remote Host Manual TCP Connection Check

A manual TCP connection check can be performed for each remote host configured for a raw socket IP transport subservice. When executed by an operator, the TCP connection check attempts to establish a TCP session toward the configured remote host. Only one TCP connection check attempt is made, with a fixed timeout of 5 s. If the attempt is successful, the session is torn down immediately without data being sent.

The TCP connection check is initiated in the CLI using the tools>perform>service>id>ip-transport>remote-host>check-tcp command. The result is displayed in the CLI using the tools>dump>service>id>ip-transport>remote-host>check-tcp command. Equivalent management is available via SNMP.

If a TCP connection to a remote host already exists due to serial traffic being transmitted, the check returns ‟successful” without impacting the existing TCP connection.

QoS Requirements for IP Transport

Serial raw socket data that is transported using an IP transport service can be DSCP marked and FC classified at the source node. This allows the source node (local host) of the traffic to mark packets correctly so that downstream nodes prioritize them as needed, and to queue local traffic in the right egress queue based on the classification assigned to the IP transport service.

Additionally, the DSCP setting is assigned per IP transport subservice for all traffic from the local host and all traffic destined for each remote host. The DCSP setting is not set per remote host.

See the dscp and fc commands under IES Raw Socket IP Transport Configuration Commands and VPRN Raw Socket IP Transport Configuration Commands for more information about configuring the QoS settings for an IES or VPRN IP transport subservice.

Service Creation Overview

Service Creation and Implementation Flowchart shows a flowchart that provides an overview of the process to create a service. Service creation can be separated into two main functional areas—core services tasks and subscriber services tasks. Core services tasks are performed prior to subscriber services tasks.

Before starting the process shown in Service Creation and Implementation Flowchart, ensure that the 7705 SAR system has been configured with an IP address and (for the 7705 SAR-8 Shelf V2 or 7705 SAR-18) has the appropriate adapter cards installed and activated.

Core services tasks include the following items:

  • create customer accounts

  • create template QoS and accounting policies

  • create LSPs

  • create SDPs

Subscriber services tasks include the following items:

  • create VLL (Apipe, Cpipe, Epipe, Fpipe, Hpipe, or Ipipe), IES, VPLS, or VPRN services

  • configure SAPs

  • bind SDPs

  • create exclusive QoS policies

  • (optionally) assign IP filter policies to Epipe SAPs, Ipipe SAPs, VPLS SAPs, VPRN interface SAPs, IES interface SAPs, and IES Management interface SAPs. IP filter policies can also be applied to VPLS SDPs (ingress mesh and spoke), and VPRN and IES interface ingress spoke SDPs.

  • (optionally) assign MAC ingress filter policies to VPLS SAPs and VPLS SDPs (mesh and spoke)

Figure 34. Service Creation and Implementation Flowchart

Port and SAP CLI Identifiers

When typing text in the command line interface (CLI), port-id is often displayed to indicate that a port identifier may need to be typed in the command line. Similarly, to identify a SAP, the port-id is used, but additional information may need to be appended to indicate a logical sub-element of the port.

On the CLI, a port-id is defined using the format slot/mda/port, where slot identifies the IOM card slot (always 1), mda identifies the physical slot in the chassis for the adapter card, and port identifies the physical port on the adapter card.

The value that can be appended to a SAP has the format [:ID], [.ID], [:ID/ID], or [:ID.ID]. The colon or dot and following ID identify a sub-element of the port (if applicable), such as a TDM channel group for a Cpipe, a VPI/VCI value for an Apipe, or a dot1q or qinq VLAN ID for an Epipe.

For example, a SAP associated with a TDM channel group on port 12 of a 16-port T1/E1 ASAP Adapter card in MDA slot 3 is identified as <1/3/12.3>, where ‟.3” is the appended value and identifies that for this SAP the channel group begins in timeslot 3.

Service Model Entities

Basic Configuration

Before configuring a subscriber service, the QoS, logs, and MPLS LSPs (if applicable) must be configured. See to the following guides for more information:

  • 7705 SAR Quality of Service Guide

  • 7705 SAR Router Configuration Guide

  • 7705 SAR System Management Guide

  • 7705 SAR MPLS Guide

A basic service configuration must have the following items configured:

  • a customer ID

  • a service type

  • a service ID (a service-id number is mandatory and a service-name is optional)

  • a SAP identifying a port and encapsulation value

  • an interface (where required) identifying an IP address, IP subnet, and broadcast address

  • an associated SDP (for distributed services)

The following example shows an Epipe service configuration displaying the SDP and Epipe service entities. SDP ID 2 was created with the far-end node 10.10.10.104. Epipe ID 6000 was created for customer ID 6, which uses the SDP ID 2.

A:ALU-B>config>service# info detail
#------------------------------------------
...
        sdp 2 mpls create
            description "MPLS-10.10.10.104"
            far-end 10.10.10.104
            ldp
            signaling tldp
            no vlan-vc-etype
            no path-mtu
            keep-alive
                shutdown
                hello-time 10
                hold-down-time 10
                max-drop-count 3
                timeout 5
                no message-length
            exit
            no shutdown
        exit
...
...
        epipe 6000 customer 6 vpn 6000 create
           service-mtu 1514
           service-name ‟Epipe_6000” 
           sap 1/1/2:0 create
               ingress
                   filter ip 1
                   qos 1
               exit
               egress
                    qos 1
               exit
           no shutdown
           exit
           spoke-sdp 2:6111 create
               ingress
                   no vc-label
           exit
               egress
                   no vc-label
           exit
               no shutdown
           exit
           no shutdown
       exit
...
#------------------------------------------
A:ALU-B>config>service#

Common Configuration Tasks

This section provides a brief overview of the following common configuration tasks that must be performed to configure a customer account and an SDP:

Configuring Customer Accounts

Use the customer command to configure customer information. Every customer account must have a customer ID. Optional parameters include:

  • description

  • contact name

  • telephone number

If special characters are included in the customer description string, such as spaces, #, or ?, the entire string must be enclosed in double quotes.

Use the following CLI syntax to create and input customer information.

CLI Syntax:
config>service# customer customer-id create
    contact contact-information
    description description-string
    phone phone-number
Example:
config>service# customer 5 create 
config>service>cust# contact "Technical Support"
config>service>cust$ description "Nokia Customer"
config>service>cust# phone "650 555-5100"
config>service>cust# exit

The following example displays the customer account configuration output.

A:ALU-12>config>service# info
-------------------------------------------
    customer 5 create
        contact "Technical Support"
        description "Nokia Customer"
        phone "650 555-5100"
    exit

Configuring SDPs

When configuring an SDP, consider the following points.

  • SDPs can be configured for MPLS, GRE, or IP encapsulation.

  • If you do not specify an encapsulation type, the default is MPLS.

  • An SDP can have more than one service bound to it. That is, an SDP is not specific or exclusive to any one service or any type of service.

  • By default, SDPs are not associated with services. After an SDP is created, services can be associated with that SDP.

  • A distributed service must be bound to an SDP.

  • When configuring a distributed service, you must identify an SDP ID and the far-end IP address. Use the show>service>sdp command to display a list of qualifying SDPs.

  • If an SDP configuration does not include the IP address of the associated far-end router, VLL and VPLS services to the far-end router cannot be provided.

  • Up to eight RSVP-TE or SR-TE LSPs can be configured under a single MPLS-encapsulated SDP. However, a mix of RSVP-TE and SR-TE LSPs is not supported. RSVP-TE LSPs are configured using the config>service>sdp>lsp command and SR-TE LSPs are configured using the config>service>sdp> sr-te-lsp command.

  • For MPLS-encapsulated SDPs, LSPs must be configured before the LSP-to-SDP associations can be assigned. The LSP-to-SDP associations must be created explicitly.

  • LSPs are configured in the config>router>mpls context. See the 7705 SAR MPLS Guide for configuration and command information.

  • The destination address of the LSPs must match the far-end IP address of the SDP.

  • The far-end SDP IP address can be the system IP address of a 7705 SAR or an SR-series router, or loopback or network interface of the far-end router

  • When configuring MPLS SDP parameters, you can either specify up to eight RSVP-TE LSPs using the config>service>sdp>lsp command or enable LDP using the config>service>sdp>ldp command. There cannot be two methods of transport in a single SDP unless the mixed-lsp-mode option is selected (the lsp and ldp commands are mutually exclusive).

    If mixed-lsp-mode is enabled and an LSP is specified, RSVP-TE is used for dynamic signaling in the LSP.

  • Automatic ingress and egress labeling (targeted LDP) is enabled by default. Ingress and egress VC labels are signaled over a targeted LDP connection between two 7705 SAR routers.

    Note: If signaling is disabled for an SDP, ingress and egress vc-labels for the services using that SDP must be configured manually.

For a basic SDP configuration, perform the following steps:

  1. Create an SDP ID.

  2. Specify an encapsulation type.

  3. Specify a far-end node.

The following examples show the CLI syntax for a basic MPLS SDP configuration. The first two show the syntax for configuring the SDP without mixed-lsp-mode enabled; one shows an RSVP-TE LSP configuration and the other shows an LDP configuration. The third example shows the syntax for configuring the SDP with mixed-lsp-mode enabled, with both an RSVP-TE LSP and LDP configured.

CLI Syntax:
config>service>sdp sdp-id mpls create
    far-end ip-addr
    lsp lsp-name
    keep-alive
        shutdown
    no shutdown 
Example:
config>service# sdp 100 mpls create
config>service>sdp# far-end 10.10.10.10
config>service>sdp# lsp "LSP1"
config>service>sdp# no shutdown
config>service>sdp# exit

The following example displays a basic SDP LSP configuration output.

*A:Sar18 Dut-B>config>service# info
----------------------------------------------
.....
        sdp 100 create
            no shutdown
            far-end 10.10.10.10
            lsp "LSP1"
            keep-alive
                shutdown
            exit
        exit
 .....
-------------------------------------------
CLI Syntax:
config>service>sdp sdp-id mpls create
    far-end ip-addr
    ldp
    keep-alive
        shutdown
    no shutdown 
Example:
config>service# sdp 300 mpls create
config>service>sdp# far-end 10.10.10.10
config>service>sdp# ldp
config>service>sdp# no shutdown
config>service>sdp# exit

The following example displays a basic SDP LDP configuration output.

*A:Sar18 Dut-B>config>service# info
----------------------------------------------
.....
        sdp 300 create
            far-end 10.10.10.10
            ldp
            keep-alive
                shutdown
            exit
            no shutdown
        exit
 .....
-------------------------------------------
CLI Syntax:
config>service>sdp sdp-id mpls create
    description description-string
    far-end ip-addr
    mixed-lsp-mode
    exit
    ldp
    lsp lsp-name
    keep-alive
        shutdown
    no shutdown 
Example:
config>service# sdp 1 mpls create
config>service>sdp# description ‟SDI4”
config>service>sdp# far-end 10.10.10.10
config>service>sdp# mixed-lsp-mode
config>service>sdp# exit
config>service>sdp# ldp
config>service>sdp# lsp "LSP1"
config>service>sdp# no shutdown
config>service>sdp# exit

The following example displays a basic SDP mixed-lsp-mode configuration output.

A:Sar18 Dut-B>config>service# info
----------------------------------------------
.....
        sdp 1 create
            description "SDI4"
            far-end 10.10.10.10
            mixed-lsp-mode
            exit
            ldp
            lsp "LSP1"
            keep-alive
                shutdown
            exit
            no shutdown
        exit
.....
----------------------------------------------

The following examples show the CLI syntax for a basic GRE SDP configuration.

CLI Syntax:
config>service>sdp sdp-id gre create
    description description-string
    far-end ip-addr
    keep-alive 
        shutdown 
    no shutdown 
Example:
config>service# sdp 2 gre create
config>service>sdp# description ‟GRE-10.10.10.10”
config>service>sdp# far-end 10.10.10.10
config>service>sdp# no shutdown
config>service>sdp# exit

The following example displays a basic GRE SDP configuration output.

A:ALU-12>config>service# info
-------------------------------------------
.....
        sdp 2  create
            description "GRE-10.10.10.104"
            far-end 10.10.10.104
            keep-alive
                shutdown
            exit
            no shutdown
.....
-----------------------------------------
A:ALU-12>config>service#

Enabling IP Fragmentation for GRE SDPs

Use the following CLI syntax to enable fragmentation of IP packets for GRE SDPs.

CLI Syntax:
config>service>sdp sdp-id gre [create]
    allow-fragmentation
Example:
config>service# sdp 2 gre create
config>service>sdp# allow-fragmentation
Note: Fragmented IP packets require a reassembly profile in order to ensure that packets that cannot be reassembled are disposed of in a timely manner. See the 7705 SAR Router Configuration Guide for configuration and command information.

Configuring Service Names

After a service has been created, it can be assigned a service name.

Use the following CLI syntax to assign a service name to a service. The syntax example is for an Epipe.

CLI Syntax:
config>service>epipe# service-name service-name 
Example:
config>service# epipe 1 customer 1 create
config>service>epipe# service-name ‟Epipe_1”

The following example displays the service name configuration output.

A:ALU-12>config>service>epipe# info
-------------------------------------------
...
            shutdown
            service-name "Epipe_1"
            sdp 2  create
                description "GRE-10.10.10.104"
                far-end 10.10.10.104
                keep-alive
                    shutdown
                exit
                no shutdown
            exit
...
-----------------------------------------
A:ALU-12>config>service#

ETH-CFM (802.1ag and Y.1731) Tasks

This section provides a brief overview of the following ETH-CFM tasks:

Configuring ETH-CFM Parameters (802.1ag and Y.1731)

Configuration commands for both the 802.1ag and the Y.1731 functions are entered in an eth-cfm context (global or Epipe or VPLS service). For information about Ethernet OAM commands for 802.1ag and Y.1731 OAM, see the ‟Ethernet OAM Capabilities” section in the 7705 SAR OAM and Diagnostics Guide.

An 802.1ag MEP and a Y.1731 MEP are similar in function. Configure a MEP to be a Y.1731 MEP by choosing the format none keywords in the global domain command, and the format icc-based keywords in the global association command. Configure a MEP to be a Y.1731 MEP that can interoperate with a 802.1ag MEP by choosing the format none keywords in the global domain command, and the format string keywords in the global association command.

802.1ag Configuration

The first set of commands occurs at the global level. The second set occurs at the Epipe or VPLS service level.

*A:ALU-1>config>eth-cfm# info
----------------------------------------------
    domain 1 name "kanata_MD" level 5
        association 1 format string name "kanata_MA"
            bridge-identifier 2
            exit
            ccm-interval 60
            remote-mepid 125
        exit
    exit
----------------------------------------------

*A:ALU-1>config>service>epipe 2 customer 1 create
*A:ALU-1>config>service>epipe# info
----------------------------------------------
    shutdown
    sap 1/5/1 create
        eth-cfm
            mep 1 domain 1 association 1 direction down
                shutdown
            exit
        exit
    exit
    spoke-sdp 1:11 create
        eth-cfm
            mep 2 domain 1 association 1 direction down
                shutdown
            exit
        exit
    exit
----------------------------------------------

*A:ALU-1>config>service>vpls 2 customer 1 create
*A:ALU-1>config>service>vpls# info
----------------------------------------------
    shutdown
    sap 1/2/1:0 create
        eth-cfm
            mep 1 domain 1 association 1 direction down
                shutdown
            exit
        exit
    exit
    mesh-sdp 7:2 create
        eth-cfm
            mep 2 domain 1 association 1 direction down
                shutdown
            exit
        exit
    exit
----------------------------------------------
Note: RDI information is carried in the CCM OAMPDU. To be able to transmit and also receive RDI information, a MEP must have CCM enabled. See Applying ETH-CFM Parameters.

Y.1731 Configuration

The following example displays a Y.1731 configuration. The first set of commands occurs at the global level. The second set occurs at the Epipe or VPLS service level.

*A:ALU-1>config>eth-cfm# info
----------------------------------------------
    domain 1 format none level 1
        association 1 format icc-based name "1234567890123"
            bridge-identifier 100
            exit
            ccm-interval 1
        exit
    exit
----------------------------------------------

*A:ALU-1>config>service>epipe# info
----------------------------------------------
    shutdown
    sap 2/2/1:40 create
        eth-cfm
            mep 1 domain 1 association 1 direction up
                ais-enable
                    priority 2
                    interval 60
                exit
                eth-test-enable
                    test-pattern all-ones crc-enable
                exit
                no shutdown
            exit
        exit
    exit
    no shutdown
...
----------------------------------------------

*A:ALU-1>config>service>vpls# info
----------------------------------------------
    shutdown
    sap 1/2/1:0 create
        eth-cfm
            mep 1 domain 1 association 1 direction up
                ais-enable
                    interval 60
                    priority 2
                exit
                eth-test-enable
                    test-pattern all-ones crc-enable
                exit
                no shutdown
            exit
        exit
    exit
    no shutdown
...
----------------------------------------------
Note: To be able to transmit and also receive AIS PDUs, a Y.1731 MEP must have ais-enable set. To be able to transmit and also receive ETH-Test PDUs, a Y.1731 MEP must have eth-test-enable set.

Applying ETH-CFM Parameters

Apply ETH-CFM parameters to the following entities, as shown in the CLI syntax examples below:

  • Epipe SAP

  • Epipe spoke SDP

  • VPLS SAP

  • VPLS spoke or mesh SDP

  • OAM tests (loopback, linktrace, Ethernet test, delay measurement, loss measurement, synthetic loss measurement)

The MAC address for a MEP on an Epipe SAP or on an Epipe or VPLS SDP cannot be changed. For a MEP on an Epipe SAP, the MAC address is the port MAC address. For a MEP on an Epipe or VPLS SDP, the MAC address is the system MAC address. The MAC address for a MEP on a VPLS SAP can be changed; the default is the port MAC address.

The 7705 SAR supports the following MEPs for both 802.1ag and Y.1731:

  • SAP Up and Down MEPs

  • spoke SDP Up and Down MEPs

  • mesh SDP Up and Down MEPs (VPLS only)

The following two syntax examples are for an Epipe service. Configuration for VPLS is the same except that the hold-mep-up-on-failure and dual-ended-loss-test-enable parameters are not supported on VPLS SAPs.

The third syntax shows the OAM tests that can be applied to MEPs.

CLI Syntax:
config>service>epipe>sap
eth-cfm
    hold-mep-up-on-failure
    mep mep-id domain md-index association ma-index [direction {up | down}]
        ais-enable
        ccm-enable
        ccm-ltm-priority priority
        dual-ended-loss-test-enable
        eth-test-enable
        low-priority-defect {allDef|macRemErrXcon| remErrXcon|errXcon|xcon|noXcon}
        one-way-delay-threshold seconds
        [no] shutdown
config>service>epipe>spoke-sdp
eth-cfm
    mep mep-id domain md-index association ma-index [direction {up | down}]
        ccm-enable
        ccm-ltm-priority priority
        low-priority-defect {allDef|macRemErrXcon| remErrXcon|errXcon|xcon|noXcon}
        [no] shutdown
oam
    eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
    eth-cfm linktrace mac-address mep mep-id domain md-index association ma-index [ttl ttl-value]
    eth-cfm loopback mac-address mep mep-id domain md-index association ma-index [send-count send-count] [size data-size] [priority priority]
    eth-cfm one-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority]
    eth-cfm two-way-delay-test mac-address mep mep-id domain md-index association ma-index [priority priority]
    eth-cfm single-ended-loss-test mac-address mep mep-id domain md-index association ma-index [priority priority] [interval interval] [send-count send-count]
    eth-cfm two-way-slm-test mac-address mep mep-id domain md-index association ma-index [priority  priority] [send-count send-count] [size data-size] [timeout timeout] [interval interval]

Service Management Tasks

This section provides a brief overview of the following service management tasks:

Modifying Customer Accounts

Use the show>service>customer command to display a list of customer IDs.

To modify a customer account:

  1. Access the specific account by specifying the customer ID.

  2. Enter the parameter to modify (description, contact, phone) and then enter the new information.

CLI Syntax:
config>service# customer customer-id create
    [no] contact contact-information
    [no] description description-string
    [no] phone phone-number
Example:
config>service# customer 27 create
config>service>customer$ description ‟Western Division”
config>service>customer# contact ‟John Dough”
config>service>customer# no phone ‟(650) 237-5102”

Deleting Customers

The no form of the customer command typically removes a customer ID and all associated information; however, all service references to the customer must be shut down and deleted before a customer account can be deleted.

CLI Syntax:
config>service# no customer customer-id
Example:
config>service# epipe 5 customer 27 shutdown
config>service# epipe 9 customer 27 shutdown
config>service# no epipe 5
config>service# no epipe 9
config>service# no customer 27

Modifying SDPs

Use the show>service>sdp command to display a list of SDP IDs.

To modify an SDP:

  1. Access the specific SDP by specifying the SDP ID.

  2. Enter the parameter to modify, such as description, far-end, or lsp, and then enter the new information.

Note: After the SDP is created, you cannot modify the SDP encapsulation type.
CLI Syntax:
config>service# sdp sdp-id 
Example:
config>service# sdp 79
config>service>sdp# description ‟Path-to-107”
config>service>sdp# shutdown
config>service>sdp# far-end ‟10.10.10.107”
config>service>sdp# path-mtu 1503
config>service>sdp# no shutdown

Deleting SDPs

The no form of the sdp command typically removes an SDP ID and all associated information; however, before an SDP can be deleted, the SDP must be shut down and removed (unbound) from all customer services where it is applied.

CLI Syntax:
config>service# no sdp 79
Example:
config>service# epipe 5 spoke-sdp 79:5
config>service>epipe>spoke-sdp# shutdown
config>service>epipe>spoke-sdp# exit
config>service>epipe 5 no spoke-sdp 79:5
config>service>epipe# exit
config>service# no sdp 79

Deleting LSP Associations

The no form of the lsp command removes an LSP ID and all associated information; however, before an LSP can be deleted, it must be removed from all SDP associations.

CLI Syntax:
config>service# sdp sdp-id 
[no] lsp lsp-name
Example:
config>service# sdp 79
config>service>sdp# no lsp 123
config>service>sdp# exit all

Global Service Command Reference

Command Hierarchies

Global Service Configuration Commands

SDP Commands
config
    - service
        - sdp sdp-id [gre | mpls | ip] [create]
        - no sdp sdp-id
            - [no] adv-mtu-override
            - [no] allow-fragmentation
            - [no] bgp-tunnel
            - description description-string
            - no description
            - encryption-keygroup keygroup-id direction {inbound | outbound} 
            - no encryption-keygroup direction {inbound | outbound} 
            - far-end [ip-address | ipv6-address]
            - no far-end
            - keep-alive
                - hello-time seconds
                - no hello-time
                - hold-down-time seconds
                - no hold-down-time
                - max-drop-count count
                - no max-drop-count
                - message-length octets
                - no message-length
                - [no] shutdown
                - timeout timeout 
                - no timeout 
            - [no] ldp 
            - [no] lsp lsp-name
            - metric metric
            - no metric
            - [no] mixed-lsp-mode 
                - revert-time {revert-time | infinite}
                - no revert-time
            - path-mtu bytes
            - no path-mtu
            - [no] shutdown
            - signaling {off | tldp}
            - [no] sr-isis
            - [no] sr-ospf
            - [no] sr-te-lsp lsp-name
            - vlan-vc-etype 0x0600..0xffff
            - no vlan-vc-etype [x0600.0xffff]
            - [no] weighted-ecmp
SAP Commands
config
    - service
        - apipe
            - sap sap-id [create]
            - no sap sap-id
        - cpipe
            - sap sap-id [create]
            - no sap sap-id
        - epipe
            - sap sap-id [create]
            - no sap sap-id
        - fpipe
            - sap sap-id [create]
            - no sap sap-id
        - hpipe
            - sap sap-id [create]
            - no sap sap-id
        - ipipe
            - sap sap-id [create]
            - no sap sap-id
        - ies
            - interface ip-int-name [create]
                - sap sap-id [create]
                - no sap sap-id
        - vprn
            - interface ip-int-name [create]
                - sap sap-id [create]
                - no sap sap-id
        - vpls
            - sap sap-id [create]
            - no sap sap-id
    - system
        - ethernet
            - [no] new-qinq-untagged-sap
Ethernet Ring Commands
config
    - [no] eth-ring ring-index
        - ccm-hold-time [down down-timeout] [up up-timeout]
        - no ccm-hold-time
        - compatible-version version
        - no compatible-version
        - description description-string
        - no description
        - guard-time time
        - no guard-time
        - node-id xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx
        - no node-id
        - path {a | b} [{port-id| lag-id | mw-link-id} raps-tag qtag1[.qtag2]]
        - no path {a | b}
            - description description-string
            - no description
            - eth-cfm
                - [no] mep mep-id domain md-index association ma-index
                    - [no] ccm-enable
                    - ccm-ltm-priority priority
                    - no ccm-ltm-priority
                    - [no] control-mep
                    - description description-string
                    - no description
                    - no eth-test-enable
                        - bit-error-threshold bit-errors
                        - test-pattern {all-zeros | all-ones} [crc-enable]
                        - no test-pattern
                    - low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
                    - one-way-delay-threshold seconds
                    - [no] shutdown
            - [no] rpl-end
            - [no] shutdown
        - revert-time time
        - no revert-time
        - rpl-node {owner | nbr}
        - no rpl-node
        - [no] shutdown
        - [no] sub-ring {virtual-link | non-virtual-link}
            - interconnect ring-id ring-index
            - interconnect vpls
            - [no] interconnect
                - [no] propagate-topology-change
ETH-CFM Commands
config
    - eth-cfm 
        - domain md-index [format {dns | mac | none | string}] name md-name level level
        - domain md-index
        - no domain md-index
            - association ma-index [format {icc-based | integer | string | vid | vpn-id}] name ma-name
            - association ma-index
            - no association ma-index
                - [no] bridge-identifier bridge-id
                    - vlan vlan-id
                    - no vlan 
                - ccm-interval {10ms | 100ms | 1 | 10 | 60 | 600}
                - no ccm-interval 
                - [no] remote-mepid mep-id
        - slm 
            - inactivity-timer timeout
            - no inactivity-timer 
Note: For information about configuring ETH-CFM commands, see the 7705 SAR OAM and Diagnostics Guide.

Show Commands

show
    - eth-ring [status]
    - eth-ring [ring-index] hierarchy
    - eth-ring ring-index [path {a | b}]
    - service
        - customer customer-id
        - sdp sdp-id keep-alive-history 
        - sdp [sdp-id] [detail]
        - sdp far-end ip-addr keep-alive-history 
        - sdp far-end ip-addr [detail] 
        - sdp-using sdp-id[:vc-id] | far-end ip-address]
        - service-using [epipe] [fpipe] [hpipe] [ies] [vprn] [mirror] [vpls] [apipe] [cpipe] [sdp sdp-id] [customer customer-id]

Monitor Commands

monitor
    - service
    - id service-id
        - sap sap-id [interval seconds] [repeat repeat] [absolute | rate]
        - sap-aggregation-group group-id [interval seconds] [repeat repeat] [absolute | rate] 

Command Descriptions

Global Service Configuration Commands

Generic Commands
description
Syntax

description description-string

no description

Context

config>service>customer

config>service>sdp

config>eth-ring

config>eth-ring>path

config>eth-ring>path>eth-cfm>mep

Description

This command creates a text description stored in the configuration file for a configuration context.

The no form of this command removes the string from the context.

Default

No description is associated with the configuration context.

Parameters
description-string

the description character string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (such as #, $, or spaces), the entire string must be enclosed within double quotes.

shutdown
Syntax

[no] shutdown

Context

config>service>sdp

config>service>sdp>keep-alive

Description

The shutdown command administratively disables an entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many objects must be shut down before they may be deleted. Many entities must be explicitly enabled using the no shutdown command.

The no form of this command places the entity into an administratively enabled state.

Services are created in the administratively down state (shutdown). When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state. Default administrative states for services and service entities are described in the following Special Cases.

Special Cases
Service Admin State

bindings to an SDP within the service will be put into the out-of-service state when the service is shut down. While the service is shut down, all customer packets are dropped and counted as discards for billing and debugging purposes.

SDP (global)

when an SDP is shut down at the global service level, all bindings to that SDP are put into the out-of-service state and the SDP itself is put into the administratively and operationally down states. Packets that would normally be transmitted using this SDP binding will be discarded and counted as dropped packets.

SDP (service level)

shutting down an SDP within a service only affects traffic on that service from entering or being received from the SDP. The SDP itself may still be operationally up for other services.

SDP Keepalives

enables SDP connectivity monitoring keepalive messages for the SDP ID. Default state is disabled (shutdown), in which case the operational state of the SDP-ID is not affected by the keepalive message state.

new-qinq-untagged-sap
Syntax

[no] new-qinq-untagged-sap

Context

config>system>ethernet

Description

This command controls the behavior of qinq SAP y.0 (for example, 1/1/1:3000.0). If this command is enabled, the y.0 SAP maps all ingress frames tagged with outer tag VLAN ID of y (qinq Ethertype) and no inner tag, or with an inner tag VLAN ID of zero (0). This behavior applies to all existing and future y.0 SAPs.

The no form of this command disables qinq untagged SAP, and the y.0 SAP will work like a y.* SAP (for example, 1/1/1:3000.*); all frames tagged with outer VLAN y and no inner VLANs, or inner VLAN x, where inner VLAN x is not specified in a SAP y.x configured on the same port (for example, 1/1/1:3000.10).

Default

no new-qinq-untagged-sap. This setting ensures that there will be no disruption for existing usage of this SAP type.

Customer Commands
customer
Syntax

customer customer-id [create]

no customer customer-id

Context

config>service

Description

This command creates a customer ID and customer context used to associate information with a particular customer. Services can later be associated with this customer at the service level.

Each customer-id must be unique and the create keyword must follow each new customer customer-id entry.

To edit a customer’s parameters, enter the existing customer customer-id without the create keyword.

Default customer 1 always exists on the system and cannot be deleted.

The no form of this command removes a customer-id and all associated information. Before removing a customer-id, all references to that customer in all services must be deleted or changed to a different customer ID.

Parameters
customer-id

specifies the ID number to be associated with the customer, expressed as an integer

Values

1 to 2147483647

contact
Syntax

contact contact-information

no contact

Context

config>service>customer

Description

This command allows you to configure contact information for a customer. Include any customer-related contact information such as a technician’s name or account contract name.

The no form of this command removes the contact information from the customer ID.

Default

No contact information is associated with the customer-id.

Parameters
contact-information

the customer contact information entered as an ASCII character string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (such as #, $, or spaces), the entire string must be enclosed within double quotes.

phone
Syntax

[no] phone phone-number

Context

config>service>customer

Description

This command adds telephone number information for a customer ID.

The no form of this command removes the phone number value from the customer ID.

Default

No telephone number information is associated with a customer.

Parameters
phone-number

the customer phone number entered as an ASCII string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (such as #, $, or spaces), the entire string must be enclosed within double quotes.

SDP Commands
sdp
Syntax

sdp sdp-id [gre | mpls | ip] [create]

no sdp sdp-id

Context

config>service

Description

This command creates or edits an SDP. SDPs must be explicitly configured.

An SDP is a (logical) service entity that is created on the local router. An SDP identifies the endpoint of a logical, unidirectional service tunnel. Traffic enters the tunnel at the SDP on the local router and exits the tunnel at the remote router. Thus, it is not necessary to specifically define far-end SAPs.

The 7705 SAR supports generic routing encapsulation (GRE) tunnels, multiprotocol label switching (MPLS) tunnels, and IP tunnels.

For MPLS, the 7705 SAR supports both signaled and non-signaled label switched paths (LSPs) through the network. Non-signaled paths are defined at each hop through the network. Signaled LSPs are established in LDP-DU (downstream unsolicited) mode. Segment routing (SR) is another MPLS tunnel type and is used to allow service binding to an SR tunnel programmed in the tunnel table manager (TTM) by OSPF or IS-IS. An SDP of type sr-isis or sr-ospf can be used with the far-end option.

SDPs are created and then bound to services. Many services may be bound to a single SDP. The operational and administrative state of the SDP controls the state of the SDP binding to the service.

If sdp-id does not exist, a new SDP is created. SDPs are created in the admin down state (shutdown). After all relevant parameters are defined, the no shutdown command must be executed before the SDP can be used.

If sdp-id exists, the current CLI context is changed to that SDP for editing and modification. If editing an existing SDP, the gre, mpls, or ip keyword is not specified. If a keyword is specified for an existing sdp-id, an error is generated and the context of the CLI is not changed to the specified sdp-id.

The no form of this command deletes the specified SDP. Before an SDP can be deleted, it must be administratively down (shutdown) and not bound to any services. If the specified SDP is bound to a service, the no sdp command fails, generating an error message specifying the first bound service found during the deletion process. If the specified sdp-id does not exist, an error is generated.

Default

n/a

Parameters
sdp-id

the SDP identifier

Values

1 to 17407

gre

specifies that the SDP will use GRE encapsulation tunnels. Only one GRE SDP is supported to a given destination 7705 SAR or 7750 SR.

mpls

specifies that the SDP will use MPLS encapsulation and one or more LSP tunnels to reach the far-end 7705 SAR or 7750 SR. Multiple MPLS SDPs are supported to a given destination service router. Multiple MPLS SDPs to a single destination service router are helpful when they use divergent paths.

ip

specifies that the SDP will use IP encapsulation tunnels. Only one IP SDP is supported to a given destination 7705 SAR because the SDP is tied to the system address of the destination LER.

adv-mtu-override
Syntax

[no] adv-mtu-override

Context

config>service>sdp

Description

This command overrides the advertised VC-type MTU. When enabled, the 7705 SAR signals a VC MTU equal to the service MTU that includes the Layer 2 header. Under normal operations it will advertise the service MTU minus the Layer 2 header. In the receive direction, it will accept either one.

The no form of this command disables the VC-type MTU override.

Default

no adv-mtu-override

allow-fragmentation
Syntax

[no] allow-fragmentation

Context

config>service>sdp

Description

This command enables GRE-encapsulated packets transmitted from the SDP to be fragmented if their size exceeds the configured network port MTU.

When allow-fragmentation is enabled, GRE-encapsulated packets that are larger than the network port MTU are fragmented and the DF bit is set to 0 by the router. Packets that are smaller than the port MTU are left unfragmented, the DF bit is set to 1 by the router, and the identification number of the packet is set to 0.

Fragmentation is supported on an SDP that has NGE (encryption-keygroup) enabled. To determine if an encrypted packet needs to be fragmented, the system compares the total packet size after NGE encryption to the network port MTU. If the encrypted packet size is larger than the MTU, the packet is fragmented. NGE decryption is performed after the packet is fully reassembled.

The no form of the command disables fragmentation of oversize GRE-encapsulated packets transmitted from the SDP.

Default

no allow-fragmentation

bgp-tunnel
Syntax

[no] bgp-tunnel

Context

config>service>sdp

Description

This command allows the use of BGP route tunnels available in the tunnel table to reach SDP far-end nodes. BGP route tunnels are only available with MPLS SDPs. Only one transport method is allowed per SDP: LDP, RSVP-LSP, BGP-tunnel, SR-ISIS, SR-OSPF, or SR-TE-LSP. This restriction is relaxed for some combinations of the transport methods when the mixed-LSP mode option is enabled on the SDP.

The no form of the command disables the use of BGP route tunnels for the SDP far end.

Default

no bgp-tunnel

encryption-keygroup
Syntax

encryption-keygroup keygroup-id direction {inbound | outbound}

no encryption-keygroup direction {inbound | outbound}

Context

config>service>sdp

Description

This command is used to bind a key group to an SDP for inbound or outbound packet processing. When configured in the outbound direction, packets egressing the node use the active-outbound-sa associated with the key group configured. When configured in the inbound direction, received packets must be encrypted using one of the valid security associations configured for the key group. Services using the SDP will be encrypted.

Encryption is enabled once the outbound direction is configured.

The no form of the command removes the key group from the SDP in the specified direction (inbound or outbound).

Default

n/a

Parameters
keygroup-id

the number of the key group being configured

Values

1 to 15 or keygroup-name (up to 64 characters)

direction {inbound | outbound}

mandatory keywords when binding a key group to a service for a particular direction

far-end
Syntax

far-end [ip-address|ipv6-address]

no far-end

Context

config>service>sdp

Description

This command configures the system IP address of the far-end destination 7705 SAR, 7750 SR, or other router ID platform for the SDP that is the termination point for a service.

The far-end IP address must be explicitly configured. The destination IP address must be a 7705 SAR, 7750 SR, or other router ID platform system IP address.

If the SDP uses GRE or IP for the destination encapsulation, the local 7705 SAR may not know that the ip-address is actually a system IP interface address on the far-end service router.

If the SDP uses MPLS encapsulation, the far-end ip-address is used to check LSP names when added to the SDP. If the ‟to IP address” defined within the LSP configuration does not exactly match the SDP far-end ip-address, the LSP will not be added to the SDP and an error message will be generated.

An SDP cannot be administratively enabled until a far-end ip-address is defined. The SDP is operational when it is administratively enabled (no shutdown).

The no form of this command removes the currently configured destination IP address for the SDP. The ip-address and ipv6-address parameters are not specified and will generate an error message if used in the no far-end command. The SDP must be administratively disabled using the config>service>sdp>shutdown command before the no far-end command can be executed. Removing the far-end IP address will cause all lsp-name associations with the SDP to be removed.

Default

n/a

Parameters
ip-address

the IPv4 address of the far-end destination router for the SDP

Values

a.b.c.d

ipv6-address

the IPv6 address of the far-end destination router for the SDP

Values

ipv6-address

x:x:x:x:x:x:x:x (eight 16-bit pieces)

x:x:x:x:x:x:d.d.d.d

   x: [0 to FFFF]H

   d: [0 to 255]D

ldp
Syntax

[no] ldp

Context

config>service>sdp

Description

This command enables LDP-signaled LSPs on MPLS-encapsulated SDPs.

In MPLS SDP configurations, up to eight RSVP-TE LSPs can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive unless mixed-LSP SDP is enabled with the mixed-lsp-mode command.

If mixed-LSP SDP is not enabled and an LSP is specified on an MPLS SDP, LDP cannot be enabled on the SDP. To enable LDP on the SDP when an LSP is already specified, the LSP must be removed from the configuration using the no lsp lsp-name command.

Default

no ldp (disabled)

lsp
Syntax

[no] lsp lsp-name

Context

config>service>sdp

Description

This command creates an association between an LSP and an MPLS SDP. This command is implemented only on MPLS-encapsulated SDPs. Up to eight RSVP-TE LSPs can be associated with a single SDP. The LSPs must have already been created in the config>router>mpls context with a valid far-end IP address. See the 7705 SAR MPLS Guide for CLI syntax and command usage.

In MPLS SDP configurations, LSPs can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive unless mixed-LSP SDP is enabled with the mixed-lsp-mode command.

If mixed-LSP SDP is not enabled and LDP is already enabled on an MPLS SDP, an LSP cannot be specified on the SDP. To specify an LSP on the SDP, LDP must be disabled.

If no LSP is associated with an MPLS SDP, the SDP cannot enter the operationally up state. The SDP can be administratively enabled (no shutdown) with no LSP associations. The lsp-name can be shut down, causing the association with the SDP to be operationally down (the LSP will not be used by the SDP).

LSP SDPs also require that the T-LDP signaling be specified and that the SDP keepalive parameter be enabled and not timed out.

The no form of this command deletes an LSP association from an SDP. If the lsp-name does not exist as an association or as a configured LSP, no error is returned. An lsp-name must be removed from all SDP associations before the lsp-name can be deleted from the system. The SDP must be administratively disabled (shutdown) before the last lsp-name association with the SDP is deleted.

Default

No LSP names are defined.

Parameters
lsp-name

the name of the LSP to associate with the SDP

metric
Syntax

metric metric

no metric

Context

config>service>sdp

Description

This command specifies the metric to be used within the tunnel table manager for decision-making purposes. When multiple SDPs going to the same destination exist, this value is used as a tiebreaker by tunnel table manager users to select the route with the lower value.

Parameters
metric

specifies the SDP metric

Values

1 to 17407

mixed-lsp-mode
Syntax

[no] mixed-lsp-mode

Context

config>service>sdp

Description

This command enables the mixed-LSP mode of operation on an SDP, which allows a primary LSP type and a backup LSP type in the same SDP configuration. For example, RSVP-TE LSPs and LDP LSPs can be configured on an SDP with the lsp and ldp commands. If mixed-LSP mode is not enabled, these commands are mutually exclusive.

Two combinations of mixed LSPs are possible:

  • an RSVP-TE primary LSP backed up by an LDP LSP

  • an LDP primary LSP backed up by a BGP LSP

Note: Mixed-LSP SDPs do not support static LSPs on either the primary or backup.

The no form of this command disables mixed-LSP; however you must remove one of the LSP types from the SDP configuration first or the command will fail.

revert-time
Syntax

revert-time {revert-time | infinite}

no revert-time

Context

config>service>sdp>mixed-lsp-mode

Description

This command configures the length of time that the service manager must wait before it resets the SDP configuration to a higher-priority LSP type when one becomes available.

The no form of the command resets the timer to the default value of 0. This means that the service manager resets the SDP configuration immediately to a higher-priority LSP type when one becomes available.

Default

0

Parameters
seconds

the time, in seconds, to wait before reverting to a higher-priority LSP type when one becomes available.

Values

0 to 600

infinite

the service manager never resets the SDP configuration to the highest-priority LSP type unless the currently active LSP fails

path-mtu
Syntax

path-mtu bytes

no path-mtu

Context

config>service>sdp

Description

This command configures the Maximum Transmission Unit (MTU) in bytes that the SDP can transmit to the far-end router without packet dropping or IP fragmentation overriding the default SDP-type path MTU.

The default SDP-type path-mtu can be overridden on a per-SDP basis.

Dynamic maintenance protocols on the SDP may override this setting.

If the physical mtu on an egress interface indicates that the next hop on an SDP path cannot support the current path-mtu, the operational path-mtu on that SDP will be modified to a value that can be transmitted without fragmentation.

The no form of this command removes any path-mtu defined on the SDP and the SDP will use the system default for the SDP type.

Default

The default path-mtu defined on the system for the type of SDP is used.

Parameters
bytes

specifies the number of bytes in the path MTU

Values

576 to 9194

signaling
Syntax

signaling {off | tldp}

Context

config>service>sdp

Description

This command specifies the signaling protocol used to obtain the ingress and egress labels in frames transmitted and received on the SDP. When signaling is off, then labels are manually configured when the SDP is bound to a service. The signaling value can only be changed while the administrative status of the SDP is down.

The no form of this command is not applicable. To modify the signaling configuration, the SDP must be administratively shut down and then the signaling parameter can be modified and re-enabled.

Default

tldp

Parameters
off

ingress and egress signal auto-labeling is not enabled. If this parameter is selected, then each service using the specified SDP must manually configure VPN labels. This configuration is independent of the SDP transport type, MPLS (LDP).

tldp

ingress and egress signaling auto-labeling is enabled

sr-isis
Syntax

[no] sr-isis

Context

config>service>sdp

Description

This command configures an MPLS SDP of LSP type IS-IS segment routing. The SDP of LSP type sr-isis can be used with the far-end option. The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off) or T-LDP (tldp).

Default

no sr-isis

sr-ospf
Syntax

[no] sr-ospf

Context

config>service>sdp

Description

This command configures an MPLS SDP of LSP type OSPF segment routing. The SDP of LSP type sr-ospf can be used with the far-end option. The signaling protocol for the service labels for an SDP using an SR tunnel can be configured to static (off) or T-LDP (tldp).

Default

no sr-ospf

sr-te-lsp
Syntax

[no] sr-te-lsp lsp-name

Context

config>service>sdp

Description

This command configures an MPLS SDP of LSP type SR-TE. Up to eight SR-TE LSPs can be configured under an SDP.

The mixed-lsp-mode option does not support the sr-te tunnel type.

The signaling protocol for the service labels for an SDP using an SR-TE LSP can be configured to static (off) or T-LDP (tldp).

Default

none

Parameters
lsp-name

the name of an LSP that has already been created

vlan-vc-etype
Syntax

vlan-vc-etype 0x0600..0xffff

no vlan-vc-etype [0x0600..0xffff]

Context

config>service>sdp

Description

This command configures the VLAN VC Ethertype. The no form of this command returns the value to the default. The etype value populates the Ethertype field in the Ethernet frame. It is used to indicate which protocol is being transported in the Ethernet frame. The default value indicates that the payload is an IEEE 802.1q-tagged frame.

Default

no vlan-vc-etype (0x8100)

Parameters
0x0600..0xffff

specifies a valid VLAN etype identifier

weighted-ecmp
Syntax

[no] weighted-ecmp

Context

config>service>sdp

Description

This command enables weighted ECMP for IES or VPRN Layer 3 spoke SDP interfaces. This command is applicable when the SDP has RSVP-TE LSPs configured using the config>service>sdp>lsp command or SR-TE LSPs configured using the config>service>sdp>sr-te-lsp command.

When weighted ECMP is enabled on an SDP, a path is selected based on the configured hash. Paths are then load-balanced across the LSPs used by the SDP according to the normalized LSP load-balancing weight configured using the load-balancing-weight command described in the 7705 SAR MPLS Guide, ‟MPLS Commands”. This means that consecutive packets of a particular service use the same LSP, but the overall load handled by LSPs to the SDP far end is balanced according to the load-balancing weight if all services using the SDP send the same bandwidth and there are more services using the SDP than there are LSPs for the SDP.

If an LSP in the ECMP set has no load-balancing weight configured, then ECMP is applied to packets based on the output of the hash for the service ID.

The no form of the command disables weighted ECMP for the SDP.

Default

no weighted-ecmp

SDP Keepalive Commands
keep-alive
Syntax

keep-alive

Context

config>service>sdp

Description

This command is the context for configuring SDP connectivity monitoring keepalive messages for the SDP-ID.

SDP-ID keepalive messages use SDP Echo Request and Reply messages to monitor SDP connectivity. The operating state of the SDP is affected by the keepalive state on the SDP-ID. SDP Echo Request messages are only sent when the SDP-ID is completely configured and administratively up. If the SDP-ID is administratively down, keepalives for that SDP-ID are disabled. SDP Echo Requests, when sent for keepalive messages, are always sent with the originator-sdp-id. All SDP-ID keepalive SDP Echo Replies are sent using generic IP OAM encapsulation.

When a keepalive response is received that indicates an error condition, the SDP ID will immediately be brought operationally down. After a response is received that indicates the error has cleared and the hold-down-time interval has expired, the SDP ID will be eligible to be put into the operationally up state. If no other condition prevents the operational change, the SDP ID will enter the operational state.

A set of event counters track the number of keepalive requests sent, the size of the message sent, non-error replies received and error replies received. A keepalive state value is kept, indicating the last response event. A keepalive state timestamp value is kept, indicating the time of the last event. With each keepalive event change, a log message is generated, indicating the event type and the timestamp value.

SDP Echo Reply Response Conditions describes keepalive interpretation of SDP Echo Reply response conditions and the effect on the SDP ID operational status.

Table 12. SDP Echo Reply Response Conditions

Result of Request

Stored Response State

Operational State

keepalive request timeout without reply

Request Timeout

Down

keepalive request not sent due to non-existent orig-sdp-id 1

Orig-SDP Non-Existent

Down

keepalive request not sent due to administratively down orig-sdp-id

Orig-SDP Admin-Down

Down

keepalive reply received, invalid origination-id

Far End: Originator-ID Invalid

Down

keepalive reply received, invalid responder-id

Far End: Responder-ID Error

Down

keepalive reply received, No Error

Success

Up (if no other condition prevents)

Note:

  1. This condition should not occur.

hello-time
Syntax

hello-time seconds

no hello-time

Context

config>service>sdp>keep-alive

Description

This command configures the time period between SDP keepalive messages on the SDP-ID for the SDP connectivity monitoring messages.

The no form of this command resets the hello-time seconds value to the default setting.

Parameters
seconds

the time period in seconds between SDP keepalive messages, expressed as a decimal integer

Values

1 to 3600

Default

10

hold-down-time
Syntax

hold-down-time seconds

no hold-down-time

Context

config>service>sdp>keep-alive

Description

This command configures the minimum time period the SDP will remain in the operationally down state in response to SDP keepalive monitoring.

This parameter can be used to prevent the SDP operational state from ‟flapping” by rapidly transitioning between the operationally up and operationally down states based on keepalive messages.

When an SDP keepalive response is received that indicates an error condition or the max-drop-count keepalive messages receive no reply, the sdp-id will immediately be brought operationally down. If a keepalive response is received that indicates the error has cleared, the sdp-id will be eligible to be put into the operationally up state only after the hold-down-time interval has expired.

The no form of this command resets the hold-down-time seconds value to the default setting.

Parameters
seconds

the time in seconds, expressed as a decimal integer, the sdp-id will remain in the operationally down state after an SDP keepalive error before it is eligible to enter the operationally up state. A value of 0 indicates that no hold-down-time will be enforced for sdp-id.

Values

0 to 3600

Default

10

max-drop-count
Syntax

max-drop-count count

no max-drop-count

Context

config>service>sdp>keep-alive

Description

This command configures the number of consecutive SDP keepalive failed request attempts or remote replies that can be missed after which the SDP is operationally downed.

If the max-drop-count consecutive keepalive request messages cannot be sent or no replies are received, the SDP-ID will be brought operationally down by the keepalive SDP monitoring.

The no form of this command resets the max-drop-count count value to the default settings.

Parameters
count

the number of consecutive SDP keepalive requests that can fail to be sent or replies missed before the SDP is brought down, expressed as a decimal integer

Values

1 to 5

Default

3

message-length
Syntax

message-length octets

no message-length

Context

config>service>sdp>keep-alive

Description

This command configures the size of SDP monitoring keepalive request messages transmitted on the SDP.

The no form of this command resets the message-length octets value to the default setting.

Parameters
octets

the size of keepalive request messages in octets, expressed as a decimal integer. The size keyword overrides the default keepalive message size.

The message length should be equal to the SDP operating path MTU as configured in the path-mtu command.

If the default size is overridden, the actual size used will be the smaller of the operational SDP-ID path MTU and the size specified.

Values

72 to 1500

Default

0

timeout
Syntax

timeout timeout

no timeout

Context

config>service>sdp>keep-alive

Description

This command configures the time interval that the SDP waits before tearing down the session.

Parameters
timeout

the timeout in seconds, expressed as a decimal integer

Values

1 to 10

Default

5

Ethernet Ring Commands
eth-ring
Syntax

[no] eth-ring ring-index

Context

config

Description

This command configures a G.8032 Ethernet ring. Ethernet rings may be configured as major rings with two paths (A and B), as sub-rings with two paths, or in the case of an interconnection node, a single path.

The no form of this command deletes the specified Ethernet ring.

Default

no eth-ring

Parameters
ring-index

specifies the Ethernet ring ID

Values

1 to 128

ccm-hold-time
Syntax

ccm-hold-time [down down-timeout] [up up-timeout]

no ccm-hold-time

Context

config>eth-ring

Description

This command configures Ethernet ring dampening timers.

The no form of the command sets the up and down timers to the default values.

Default

down 0

up 20

Parameters
down-timeout

specifies the down timeout, in centiseconds

Values

0 to 5000

Default

0

up-timeout

specifies the hold-time for reporting the recovery, in deciseconds

Values

0 to 5000

Default

20

compatible-version
Syntax

compatible-version version

no compatible-version

Context

config>eth-ring

Description

This command configures Ethernet ring compatibility version for the G.8032 state machine and messages. The default is version 2 and all router switches use version 2. The version can be changed if there is a need to interwork with third party devices that only support version 1.

The no form of this command sets the compatibility version to 2.

Default

2

Parameters
version

specifies the version of the G.8032 state machine

Values

1 or 2

guard-time
Syntax

guard-time time

no guard-time

Context

config>eth-ring

Description

This command configures the guard time for an Ethernet ring.

The no form of this command restores the default guard time.

Default

5

Parameters
value

specifies the guard time, in deciseconds

Values

1 to 20

Default

5

node-id
Syntax

node-id xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx

no node-id

Context

config>eth-ring

Description

This optional command configures the MAC address of the RPL link. The default is to use the chassis MAC address for the ring control. This command allows the chassis MAC address to be overridden with another MAC address.

The no form of the command removes the RPL link.

Default

no node-id

Parameters
xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx

specifies the MAC address

path
Syntax

path {a | b} [{port-id | lag-id| mw-link-id} raps-tag qtag1[.qtag2]]

no path {a | b}

Context

config>eth-ring

Description

This command assigns the Ethernet ring (major or sub-ring) path to a port and defines the Ethernet ring APS tag. Rings typically have two paths, A or B.

The no form of this command removes the configured path.

Default

no path

Parameters
port-id

the port ID

Values

slot/mda/port

lag-id

the LAG ID

Values

lag — Keyword.

id — Specifies the LAG ID number.

mw-link-id

specifies the microwave link ID number, using the form mw-link-num

Values

num = 1 to 24

raps-tag

the Ethernet ring member’s encapsulation

qtag1

specifies the top or outer VLAN ID

Values

1 to 4094

qtag2

specifies the bottom or inner VLAN ID

Values

1 to 4094

eth-cfm
Syntax

eth-cfm

Context

config>eth-ring>path

Description

This command enables the context to configure Ethernet CFM parameters.

mep
Syntax

[no] mep mep-id domain md-index association ma-index

Context

config>eth-ring>path>eth-cfm

Description

This command provisions an 802.1ag maintenance endpoint (MEP).

The no form of the command deletes the MEP.

Parameters
mep-id

specifies the MEP identifier

Values

1 to 81921

md-index

specifies the MD index value

Values

1 to 4294967295

ma-index

specifies the MA index value

Values

1 to 4294967295

ccm-enable
Syntax

[no] ccm-enable

Context

config>eth-ring>path>eth-cfm>mep

Description

This command enables the generation of CCM messages.

The no form of the command disables the generation of CCM messages.

Default

no ccm-enable

ccm-ltm-priority
Syntax

ccm-ltm-priority priority

no ccm-ltm-priority

Context

config>eth-ring>path>eth-cfm>mep

Description

This command specifies the priority value for CCMs and LTMs transmitted by the MEP.

The no form of the command removes the priority value from the configuration.

Default

The highest priority on the bridge port.

Parameters
priority

specifies the priority of CCM and LTM messages

Values

0 to 7

control-mep
Syntax

[no] control-mep

Context

config>eth-ring>path>eth-cfm>mep

Description

This command enables Ethernet ring control on the MEP. Configuration of this command is mandatory for a ring. MEP detection of failure using CCM can be enabled or disabled independently of the control MEP.

The no form of this command disables Ethernet ring control.

Default

no control-mep

eth-test-enable
Syntax

[no] eth-test-enable

Context

config>eth-ring>path>eth-cfm>mep

Description

This command enables Ethernet test functionality on the MEP. For the test to work, operators need to configure Ethernet test parameters on both the sender and receiver nodes. The Ethernet test can be performed using the oam>eth-cfm>eth-test command.

A check is done for both the provisioning and the test to ensure the MEP is a Y.1731 MEP, provisioned with domain format none and associated with format icc-based. If they are not, the command fails and an error message is generated in the CLI and SNMP indicating the problem.

Default

no eth-test-enable

bit-error-threshold
Syntax

bit-error-threshold bit-errors

Context

config>eth-ring>path>eth-cfm>mep>eth-test-enable

Description

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

Default

1

Parameters
bit-errors

specifies the lowest priority defect

Values

0 to 11840

test-pattern
Syntax

test-pattern {all-zeros | all-ones} [crc-enable]

no test-pattern

Context

config>eth-ring>path>eth-cfm>mep>eth-test-enable

Description

This command configures the test pattern for Ethernet test frames.

The no form of the command removes the test pattern from the Ethernet test configuration.

Default

all-zeros

Parameters
all-zeros

configures the test pattern with all zeros

all-ones

configures the test pattern with all ones

crc-enable

generates a CRC checksum

low-priority-defect
Syntax

low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}

Context

config>eth-ring>path>eth-cfm>mep

Description

This command specifies the lowest priority defect that will generate a fault alarm.

Default

remErrXcon

Parameters
allDef

all defects (DefRDICCM, DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM) generate a fault alarm

macRemErrXcon

DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM generate a fault alarm

remErrXcon

DefRemoteCCM, DefErrorCCM, and DefXconCCM generate a fault alarm

errXcon

DefErrorCCM and DefXconCCM generate a fault alarm

xcon

DefXconCCM generates a fault alarm

noXcon

no defects DefXcon or lower generate a fault alarm

one-way-delay-threshold
Syntax

one-way-delay-threshold seconds

Context

config>eth-ring>path>eth-cfm>mep

Description

This command configures a one-way delay threshold time limit.

Default

3

Parameters
seconds

the threshold value, in seconds

Values

0 to 600

rpl-end
Syntax

[no] rpl-end

Context

config>eth-ring>path

Description

This command configures the G.8032 path as a ring protection link (RPL) end. The ring must be declared as either an RPL owner or an RPL neighbor in order for this command to be valid. Only a path configured as A or B can be configured as an RPL end.

The no form of this command reverts to the default.

Default

no rpl-end

revert-time
Syntax

revert-time time

no revert-time

Context

config>eth-ring

Description

This command configures the revert time for an Ethernet ring. It ranges from 60 s to 720 s.

The no form of this command means that the Ethernet ring is in non-revertive mode and the revert time is essentially 0. The revert timers are not set.

Default

300

Parameters
time

specifies the revert time, in seconds

Values

60 to 720

rpl-node
Syntax

rpl-node {owner | nbr}

no rpl-node

Context

config>eth-ring

Description

This command configures the G.8032 ring protection link type as either owner or neighbor. The no form of the command means this node is not connected to an RPL link. When an RPL owner or neighbor is specified, either the A or B path must be configured with the rpl-end command. An owner is responsible for operation of the RPL link. The link can be left with no RPL type configured, but if this command is used the nbr parameter is mandatory.

On a sub-ring without a virtual channel, it is mandatory to configure a sub-ring non-virtual-link on all nodes on the sub-ring to propagate the RAPS messages around the sub-ring.

The no form of this command removes the RPL link.

Default

no rpl-node

sub-ring
Syntax

[no] sub-ring {virtual-link | non-virtual-link}

Context

config>eth-ring

Description

This command defines an Ethernet ring as a sub-ring as defined in G.8032. A sub-ring can have only one valid path connecting it to a major ring or to a VPLS instance. The virtual-link parameter indicates that a sub-ring is connected to another ring and that control messages can be sent over the attached ring to the other side of the sub-ring. The non-virtual-link channel parameter indicates that a sub-ring may be connected to a another ring or to a VPLS instance but that control messages from the sub-ring can not use the attached ring or VPLS instance. The non-virtual channel behavior is standard G.8032 capability.

The no form of this command deletes the sub-ring and its virtual channel associations.

Default

no sub-ring

Parameters
virtual-link

specifies that the interconnection is to a ring and a virtual link will be used

non-virtual-link

specifies that the interconnection is to a ring or a VPLS instance and a virtual link will not be used

interconnect
Syntax

interconnect ring-id ring-index

interconnect vpls

no interconnect

Context

config>eth-ring>sub-ring

Description

This command links the G.8032 sub-ring to a ring instance or to a VPLS instance. The ring instance must be a complete ring with two paths but may itself be a sub-ring or a major ring, as declared by its configuration on another node. When the interconnection is to another node, the sub-ring may have a virtual link or a non-virtual-link. When the sub-ring has been configured with a non-virtual link, the sub-ring may be alternatively be connected to a VPLS service. This command is only valid on the interconnection node where a single sub-ring port connects to a major ring or terminates on a VPLS service.

The no form of this command removes the interconnect node.

Default

no interconnect

Parameters
ring-index

specifies the identifier for the ring instance of the connection ring for this sub-ring on this node

Values

0 to 128

vpls

specifies that the sub-ring is connected to the VPLS instance that contains the sub-ring SAP

propagate-topology-change
Syntax

[no] propagate-topology-change

Context

config>eth-ring>sub-ring>interconnect

Description

This command configures the G.8032 sub-ring to propagate topology changes from the sub-ring to the major ring as specified in the G.8032 interconnection flush logic. This command is only valid on a sub-ring and the interconnection node. A virtual link or non-virtual link must be specified for this command to be valid. The command is blocked on major rings (when both path A and B are specified on a ring).

The no form of this command disables topology propagation.

Default

no propagate-topology-change

Show Commands

Note: The following command outputs are examples only; actual displays may differ depending on supported functionality and user configuration.
eth-ring
Syntax

eth-ring [status]

eth-ring [ring-index] hierarchy

eth-ring ring-index [path {a | b}]

Context

show

Description

This command displays Ethernet ring information.

Parameters
status

displays an Ethernet ring status summary

ring-index

specifies an Ethernet ring index

Values

1 to 32

hierarchy

displays Ethernet ring hierarchical relationships

path

displays information for a specific path

Output

The following output is an example of Ethernet ring information and Ethernet Ring Command Field Descriptions describes the fields.

Output Example
*A:7705:Dut-A# show eth-ring status 
===============================================================================
Ethernet Ring (Status information)
===============================================================================
Ring   Admin  Oper       Path Information                 MEP Information
ID     State  State  Path         Tag       State     Ctrl-MEP CC-Intvl Defects
-------------------------------------------------------------------------------
1      Up     Up     a - lag-32       1     Up        Yes      100ms     -----
                     b - 1/1/1        1     Up        Yes      100ms     -----
2      Up     Up     a - lag-32       3.3   Up        Yes      100ms     -----
                     b - 1/1/1        3.3   Up        Yes      100ms     -----
3      Up     Up     a - 1/1/3        5.5   Up        Yes      100ms     -----
                     b - N/A                 -        -        -         -----
===============================================================================
Ethernet Tunnel MEP Defect Legend:
R = Rdi, M = MacStatus, C = RemoteCCM, E = ErrorCCM, X = XconCCM

*A:7705:Dut-A# show eth-ring 1 hierarchy 
===============================================================================
Ethernet Ring 1 (hierarchy)
===============================================================================
Ring Int  Admin Oper            Paths Summary                       Path States
ID   ID   State State                                               a     b
-------------------------------------------------------------------------------
1    -    Up    Up    a - lag-32       1     b - 1/1/1        1     U     U    
3    1    Up    Up    a - 1/1/3        5.5   b - Not configured     B     -    
===============================================================================
Ethernet Ring Summary Legend:   B - Blocked    U - Unblocked

*A:7705:Dut-A# show eth-ring 1 path a    
===============================================================================
Ethernet Ring 1 Path Information
===============================================================================
Description        : Ethernet Ring : 1 Path : pathA
Port               : lag-32             Raps-Tag         : 1.0
Admin State        : Up                 Oper State       : Up
Path Type          : normal             Fwd State        : unblocked
                                        Fwd State Change : 03/19/2019 18:51:35
Last Switch Command: noCmd              
APS Rx PDU         : Request State: 0x0
                     Sub-Code     : 0x0
                     Status       : 0xE0  ( RB DNF BPR )
                     Node ID      : 94:e9:8c:0c:db:d9
===============================================================================

*A:7705:Dut-A# show eth-ring 1 path b 
===============================================================================
Ethernet Ring 1 Path Information
===============================================================================
Description        : Ethernet Ring : 1 Path : pathB
Port               : 1/1/1              Raps-Tag         : 1.0
Admin State        : Up                 Oper State       : Up
Path Type          : normal             Fwd State        : unblocked
                                        Fwd State Change : 03/19/2019 18:51:39
Last Switch Command: noCmd              
APS Rx PDU         : Request State: 0x0
                     Sub-Code     : 0x0
                     Status       : 0xE0  ( RB DNF BPR )
                     Node ID      : 94:e9:8c:0c:db:d9
===============================================================================
*A:7705:Dut-A#
Table 13. Ethernet Ring Command Field Descriptions

Label

Description

Ring ID

Displays the Ethernet ring ID number

Admin State

Up – the Ethernet ring or path is administratively enabled

Down – the Ethernet ring or path is administratively disabled

Oper State

Up – the Ethernet ring or path is operationally enabled

Down – the Ethernet ring or path is operationally disabled

Path

Displays the configured Ethernet ring path

Tag

Displays the APS tag

Ctrl-MEP

Indicates whether the MEP is configured as a control MEP

CC-Intvl

Displays the configured CCM interval value

Defects

Displays any Ethernet tunnel MEP defects

Int ID

Displays the interface ID

Path States

Displays the state of Ethernet ring paths

B – Blocked

U – Unblocked

Description

Displays the Ethernet ring path description

Fwd State

Displays the forwarding state of the path

Fwd State Change

Displays the date and time of the last change to the path’s forwarding state

customer
Syntax

customer customer-id

Context

show>service

Description

This command displays service customer information.

Parameters
customer-id

displays only information for the specified customer ID

Values

1 to 2147483647

Default

all customer IDs display

Output

The following output is an example of customer information, and Customer Command Field Descriptions describes the fields.

Output Example
*A:ALU-12# show service customer
==========================================================
Customers
==========================================================
Customer-ID : 1
Contact : Manager
Description : Default customer
Phone : (123) 555-1212

Customer-ID : 2
Contact : Tech Support
Description : ABC Networks
Phone : (234) 555-1212

Customer-ID : 3
Contact : Fred
Description : ABC Networks
Phone : (345) 555-1212

Customer-ID : 6
Contact : Ethel
Description : Epipe Customer
Phone : (456) 555-1212

Customer-ID : 7
Contact : Lucy
Description : VPLS Customer
Phone : (567) 555-1212

Customer-ID : 8
Contact : Customer Service
Description : IES Customer
Phone : (678) 555-1212

Customer-ID : 274
Contact : Mssrs. Beaucoup
Description : ABC Company
Phone : 650 123-4567

Customer-ID : 94043
Contact : Test Engineer on Duty
Description : TEST Customer
Phone : (789) 555-1212
------------------------------------------------------
Total Customers : 8
-----------------------------------------------------------
*A:ALU-12#
*A:ALU-12# show service customer 274
==============================================================================
Customer 274
==============================================================================
Customer-ID : 274
Contact : Mssrs. Beaucoup
Description : ABC Company
Phone : 650 123-4567
------------------------------------------------------------------------------
Total Customers : 1
------------------------------------------------------------------------------
*A:ALU-12#
Table 14. Customer Command Field Descriptions

Label

Description

Customer-ID

Displays the unique customer identification number

Contact

Displays the name of the primary contact person

Description

Displays generic information about the customer

Phone

Displays the telephone or pager number used to reach the primary contact person

Total Customers

Displays the total number of customers configured

sdp
Syntax

sdp sdp-id keep-alive-history

sdp [sdp-id] [detail]

sdp far-end ip-addr keep-alive-history

sdp far-end ip-addr [detail]

Context

show>service

Description

This command displays SDP information.

If no optional parameters are specified, a summary SDP output for all SDPs is displayed.

Parameters
sdp-id

the SDP ID for which to display information

Values

1 to 17407

Default

all SDPs

ip-address

displays only SDPs matching with the specified far-end IP address

Default

SDPs with any far-end IP address

detail

displays detailed SDP information

keep-alive-history

displays the last fifty SDP keepalive events for the SDP

Output

The following output is an example of service SDP information, and Service SDP Field Descriptions describes the fields.

Output Example
*A:Sar18 Dut-B>show>service# sdp
============================================================================
Services: Service Destination Points
============================================================================
SdpId  AdmMTU  OprMTU  Far End          Adm  Opr         Del     LSP   Sig
----------------------------------------------------------------------------
8      0       0       10.10.10.10      Down Down        MPLS          TLDP
11     0       0                        Down Down        MPLS          TLDP
30     0       0                        Down Down        MPLS          TLDP
900    0       0       10.10.10.10      Down Down        MPLS          TLDP
1000   0       1546    1.1.1.1          Up   Up          MPLS    L     TLDP
----------------------------------------------------------------------------
Number of SDPs : 5
----------------------------------------------------------------------------
Legend: R = RSVP, L = LDP, B = BGP, M = MPLS-TP, n/a = Not Applicable
        I = SR-ISIS, O = SR-OSPF, T = SR-TE, F = FPE
============================================================================
*A:Sar18 Dut-B>show>service#
*A:Sar18 Dut-B>show>service# sdp 8
============================================================================
Service Destination Point (Sdp Id : 8)
============================================================================
SdpId  AdmMTU  OprMTU  Far End          Adm  Opr         Del     LSP   Sig
----------------------------------------------------------------------------
8      0       0       10.10.10.10      Down Down        MPLS          TLDP
============================================================================
*A:Sar18 Dut-B>show>service#
*A:Sar18 Dut-B>show>service# sdp 1000 detail
===============================================================================
Service Destination Point (Sdp Id : 1000) Details
===============================================================================
-------------------------------------------------------------------------------
 Sdp Id 1000  -1.1.1.1
-------------------------------------------------------------------------------
Description           : (Not Specified)
SDP Id               : 1000                  SDP Source         : manual
Admin Path MTU       : 0                     Oper Path MTU      : 1546
Delivery             : MPLS
Far End              : 1.1.1.1
Tunnel Far End       : 1.1.1.1               LSP Types          : LDP

Admin State          : Up                    Oper State         : Up
Signaling            : TLDP                  Metric             : 0
Last Status Change   : 05/23/2018 18:41:32   Adv. MTU Over.     : No
Last Mgmt Change     : 05/23/2018 18:41:05   VLAN VC Etype      : 0x8100
Flags                : None

Mixed LSP Mode Information :
Mixed LSP Mode       : Enabled               Active LSP Type    : LDP
Revert Time          : 0                     Revert Count Down  : n/a

KeepAlive Information :
Admin State          : Disabled              Oper State         : Disabled
Hello Time           : 10                    Hello Msg Len      : 0
Hello Timeout        : 5                     Unmatched Replies  : 0
Max Drop Count       : 3                     Hold Down Time     : 10
Tx Hello Msgs        : 0                     Rx Hello Msgs      : 0

-------------------------------------------------------------------------------
BGP Tunnel Information :
-------------------------------------------------------------------------------
BGP LSP Id           : 0 

-------------------------------------------------------------------------------
LDP Information :
-------------------------------------------------------------------------------
LDP LSP Id           : 65537

-------------------------------------------------------------------------------
RSVP/Static LSPs
-------------------------------------------------------------------------------
Associated LSP List :
No LSPs Associated

-------------------------------------------------------------------------------
Segment Routing
-------------------------------------------------------------------------------
ISIS                 : disabled
OSPF                 : disabled
TE-LSP               : disabled
-------------------------------------------------------------------------------
Group Encryption
-------------------------------------------------------------------------------
Inbound Keygroup Id  : N/A
Outbound Keygroup Id : N/A
===============================================================================
*A:Sar18 Dut-B>show>service# *
*A:ALU-12>show>service# sdp 11 keep-alive-history
===============================================================================
Service Destination Point (Sdp Id : 5001)
===============================================================================
Time of Probe Report      RTT(ms) Size   Status
-------------------------------------------------------------------------------
2010/11/30 11:27:32       1011    72     Response Received                     
2010/11/30 11:27:22       1001    72     Response Received                     
2010/11/30 11:27:12       1001    72     Response Received                     
2010/11/30 11:27:02       1001    72     Response Received                     
2010/11/30 11:26:58       1002    72     Response Received                     
===============================================================================
*A:ALU-12>show>service#
Table 15. Service SDP Field Descriptions

Label

Description

SDP Id

Identifies the SDP

Description

Identifies the SDP by the text description stored in its configuration file

SDP Source

Specifies the SDP source type

Adm MTU (Adm Path MTU)

Specifies the desired largest service frame size (in octets) that can be transmitted through this SDP to the far-end router

Opr MTU (Opr Path MTU)

Specifies the actual largest service frame size (in octets) that can be transmitted through this SDP to the far-end router

Delivery

Specifies the delivery routing protocol

Far End

Specifies the IP address of the remote end of the GRE or MPLS tunnel defined by this SDP

Tunnel Far End

On the 7705 SAR, tunnel far end is the same as the SDP far end and is not configurable

LSP Types

Specifies the supported LSP types: R = RSVP, L = LDP, B = BGP, I = SR-ISIS, O = SR-OSPF, T = SR-TE, and n/a = Not Applicable

Adm (Admin State)

Specifies the desired state of the SDP

Opr (Oper State)

Specifies the operating state of the SDP

Del (Delivery)

Specifies the type of delivery used by the SDP: MPLS, GRE, or IP

Sig (Signaling)

Specifies the signaling protocol used to obtain the ingress and egress labels used in frames transmitted and received on the SDP

Metric

Specifies the value used as a tiebreaker by the tunnel table manager to select a route

Last Status Change

Specifies the time of the most recent operating status change to this SDP

Last Mgmt Change

Specifies the time of the most recent management-initiated change to this SDP

Adv. MTU Over

Specifies the state of the advertised VC-type MTU override command

VLAN VC Etype

Specifies the VLAN VC Ethertype for the SDP

Flags

Specifies all the conditions that affect the operating status of this SDP

Number of SDPs

Specifies the total number of SDPs displayed according to the criteria specified

Mixed LSP Mode Information:

Mixed LSP Mode

Indicates whether mixed-LSP mode is configured on the SDP

Active LSP Type

Indicates the active LSP type on the mixed-LSP SDP: RSVP or LDP

Revert Time

The number of seconds the service manager must wait before it resets the SDP configuration to a higher priority LSP type when one becomes available

Keepalive Information:

Admin State

Specifies the desired keepalive state

Oper State

Specifies the operating keepalive state

Hello Time

Specifies how often the SDP Echo Request messages are transmitted on this SDP

Hello Msg Len

Specifies the length of the SDP Echo Request messages transmitted on this SDP

Hello Timeout

Specifies the number of seconds to wait for an SDP echo response message before declaring a timeout

Unmatched Replies

Specifies the number of SDP unmatched message replies timer expired

Max Drop Count

Specifies the maximum number of consecutive SDP Echo Request messages that can be unacknowledged before the keepalive protocol reports a fault

Hold Down Time

Specifies the amount of time to wait before the keepalive operating status is eligible to enter the alive state

TX Hello Msgs

Specifies the number of SDP echo request messages transmitted since the keepalive was administratively enabled or the counter was cleared

Rx Hello Msgs

Specifies the number of SDP echo request messages received since the keepalive was administratively enabled or the counter was cleared

Collect Stats.

Specifies that the collection of accounting and statistical data for the SDP is enabled or disabled

Keepalive History:

Time of Probe Report

Indicates the date and time of the report

RTT (ms)

Indicates round-trip time (RTT), in milliseconds.

Size

Indicates the size of the packet, in bytes

Status

Indicates the status of the response

LDP Information:

LDP LSP Id

Indicates the LDP LSP identifier

RSVP/Static LSPs:

Associated LSP List

Lists the associated LSPs

If the SDP type is MPLS, a list of LSPs used to reach the far-end router displays. All the LSPs in the list must terminate at the IP address specified in the far-end field

If the SDP type is GRE, the following message displays:

SDP Delivery Mechanism is not MPLS

Lsp Name

For MPLS: identifies the name of the static LSP

Time since Last Trans*

For MPLS: specifies the time that the associated static LSP has been in service

Segment Routing

ISIS

Indicates the state of IS-IS segment routing: enabled or disabled

OSPF

Indicates the state of OSPF segment routing: enabled or disabled

TE-LSP

Indicates the state of TE-LSP segment routing: enabled or disabled

Group Encryption

Inbound Keygroup Id

Indicates the key group used to decrypt inbound traffic for the service

Outbound Keygroup Id

Indicates the key group used to encrypt outbound traffic for the service

sdp-using
Syntax

sdp-using [sdp-id[:vc-id] | far-end ip-address]

Context

show>service

Description

This command displays services using SDP or far-end address options.

Parameters
sdp-id

displays only services bound to the specified SDP ID

Values

1 to 17407

vc-id

the virtual circuit identifier

Values

1 to 4294967295

ip-address

displays only services matching with the specified far-end IP address

Default

services with any far-end IP address

Output

The following output is an example of service SDP-using information, and Service SDP-Using Field Descriptions describes the fields.

Output Example
*A:ALU-1# show service sdp-using 300
===============================================================================
Service Destination Point (Sdp Id : 300)
===============================================================================
SvcId       SdpId               Type Far End        Opr State I.Label  E.Label
-------------------------------------------------------------------------------
1           300:1               Spok 10.0.0.13      Up        131071   131071
2           300:2               Spok 10.0.0.13      Up        131070   131070
100         300:100             Spok 10.0.0.13      Up        131069   131069
101         300:101             Spok 10.0.0.13      Up        131068   131068
102         300:102             Spok 10.0.0.13      Up        131067   131067
-------------------------------------------------------------------------------
Number of SDPs : 7
-------------------------------------------------------------------------------
===============================================================================
Table 16. Service SDP-Using Field Descriptions

Label

Description

SvcId

Identifies the service

SdpId

Identifies the SDP

Type

Indicates the type of SDP (mesh or spoke)

Far End

Displays the far-end address of the SDP

Opr State

Displays the operational state of the service

I. Label

Displays the ingress label used by the far-end device to send packets to this device in this service by this SDP

E. Label

Displays the egress label used by this device to send packets to the far-end device in this service by this SDP

service-using
Syntax

service-using [epipe] [fpipe] [hpipe] [ies] [vpls] [vprn] [mirror] [apipe] [ipipe] [cpipe] [sdp sdp-id] [customer customer-id]

Context

show>service

Description

This command displays the services matching specific usage properties.

If no optional parameters are specified, all services defined on the system are displayed.

Parameters
epipe

displays matching Epipe services

ies

displays matching IES services

vpls

displays matching VPLS services

vprn

displays matching VPRN services

mirror

displays matching mirror services

apipe

displays matching Apipe services

cpipe

displays matching Cpipe services

fpipe

displays matching Fpipe services

hpipe

displays matching Hpipe services

sdp-id

displays only services bound to the specified SDP ID

Values

1 to 17407

Default

services bound to any SDP ID

customer-id

displays services only associated with the specified customer ID

Values

1 to 2147483647

Default

services associated with a customer

Output

The following outputs are examples of service-using information, and Service Service-Using Field Descriptions describes the fields.

Output Example – all services used in system
*A:ALU-12# show service service-using 
===============================================================================
Services 
===============================================================================
ServiceId    Type      Adm    Opr        CustomerId        Service Name    
-------------------------------------------------------------------------------
1            Cpipe     Down   Down       1                 cpipe_1_global 
2            Apipe     Down   Down       1                 apipe_2 
103          Epipe     Up     Up         104               epipe_103_sales 
104          Epipe     Up     Up         104               epipe_104_marketing 
105          Epipe     Up     Up         104               epipe_105_finance 
303          Cpipe     Up     Up         104                
304          Cpipe     Up     Up         104                
305          Cpipe     Up     Up         104                
701          Apipe     Up     Down       1                  
702          Apipe     Up     Down       1                  
703          Apipe     Up     Down       1                  
704          Apipe     Up     Down       1                  
807          Apipe     Up     Down       1                  
808          Apipe     Up     Down       1                  
903          Cpipe     Up     Up         1                  
904          Cpipe     Up     Up         1                  
5000         VPLS      Down   Down       1                  vpls_5000_sales
5001         VPLS      Down   Down       1                  
-------------------------------------------------------------------------------
Matching Services : 19
*A:7705:Dut-A# show service service-using 
===============================================================================
Services 
===============================================================================
ServiceId    Type      Adm    Opr        CustomerId        Service Name    
-------------------------------------------------------------------------------
100          Mirror    Up     Up         1                 XYZ Mirror 100 
1000         Epipe     Up     Up         1                 XYZ Epipe 1000 
2000         VPLS      Up     Up         1                
2100         VPLS      Up     Up         1                 rVpls2100 
2200         Ipipe     Up     Up         1                  
3000         IES       Up     Up         1                 XYZ Ies 3000 
3500         VPRN      Up     Up         1                 XYZ Vprn 3500 
4050         IES       Up     Up         1                 XYZ Ies 4050
-------------------------------------------------------------------------------
Matching Services : 8
Output Example – services used by customer
*A:ALU-12# show service service-using customer 1
===============================================================================
Services  Customer 1
===============================================================================
ServiceId    Type      Adm    Opr        CustomerId        Service Name    
-------------------------------------------------------------------------------
1            Cpipe     Down   Down       1                 cpipe_1_global 
2            Apipe     Down   Down       1                 apipe_2
701          Apipe     Up     Down       1                  
702          Apipe     Up     Down       1                 
703          Apipe     Up     Down       1                  
704          Apipe     Up     Down       1                 
807          Apipe     Up     Down       1                  
808          Apipe     Up     Down       1                  
903          Cpipe     Up     Up         1                  
904          Cpipe     Up     Up         1                  
5000         VPLS      Down   Down       1                  vpls_5000_sales
5001         VPLS      Down   Down       1                 
-------------------------------------------------------------------------------
Matching Services : 13
*A:ALU-12#
Output Example – services by service type (epipe)
*A:ALU-12# show service service-using epipe
===============================================================================
Services [epipe]
===============================================================================
ServiceId    Type      Adm    Opr        CustomerId        Service Name    
-------------------------------------------------------------------------------
103          Epipe     Up     Up         104               epipe_103_sales 
104          Epipe     Up     Up         104               epipe_104_marketing 
105          Epipe     Up     Up         104               epipe_105_finance 
-------------------------------------------------------------------------------
Matching Services : 3
*A:ALU-12#
Table 17. Service Service-Using Field Descriptions

Label

Description

Service Id

Identifies the service

Type

Specifies the service type configured for the service ID

Adm

Displays the desired state of the service

Opr

Displays the operating state of the service

CustomerID

Displays the ID of the customer who owns this service

Service Name

The service name

Monitor Commands

service
Syntax

service

Context

monitor

Description

This command enables the context to configure criteria to monitor specific service SAP criteria.

id
Syntax

id service-id

Context

monitor>service

Description

This command displays statistics for a specific service, specified by the service-id, at the configured interval until the configured count is reached.

The first screen displays the current statistics related to the service-id. The subsequent statistical information listed for each interval is displayed as a delta to the previous screen output.

When the keyword rate is specified, the rate per second for each statistic is displayed instead of the delta.

Monitor commands are similar to show commands, but only statistical information is displayed. Monitor commands display the selected statistics according to the configured number of times at the interval specified.

Parameters
service-id

identifies the service in the service domain

Values

1 to 2147483690 or service-name

sap
Syntax

sap sap-id [interval seconds] [repeat repeat] [absolute | rate]

Context

monitor>service>id

Description

This command displays statistics for a SAP associated with this service.

This command displays statistics for a specific SAP, identified by the port ID and encapsulation value, at the configured interval until the configured count is reached.

The first screen displays the current statistics related to the SAP. The subsequent statistical information listed for each interval is displayed as a delta to the previous screen output.

When the keyword rate is specified, the rate per second for each statistic is displayed instead of the delta.

Monitor commands are similar to show commands, but only statistical information is displayed. Monitor commands display the selected statistics according to the configured number of times at the interval specified.

Parameters
sap-id

identifies the SAP for the service

The sap-id can be configured in one of the formats described in SAP ID Configurations . The range of values for the parameters follow the table.

Table 18. SAP ID Configurations

Type

Syntax

Example

port-id

slot/mda/port[.channel]

1/1/5

bridge

slot/mda/<bridge-id.branch-id>

1/5/16.10

null

[port-id | bundle-id | lag-id | aps-id | mw-link-id]

port-id: 1/1/3

bundle-id: bundle-ppp-1/1.1

lag-id: lag-1

aps-id: aps-1

mw-link-id: mw-link-1

dot1q

[port-id | lag-id | aps-id | mw-link-id]:qtag1

port-id:qtag1: 1/1/3:100

lag-id: lag-1:10

aps-id: aps-1

mw-link-id: mw-link-1

qinq

[port-id | lag-id]:qtag1.qtag2

port-id:qtag1.qtag2: 1/1/3:100.30

lag-id: lag-1:10.10

atm

[port-id | aps-id][:vpi/vci | vpi | vpi1.vpi2]1

port-id: 1/1/1 or 1/1/1.1 (for T1/E1 channelized ports)

aps-id: aps-1

vpi/vci: 16/26

vpi: 16

vpi1.vpi2: 16.22

lag

lag-id

lag-2

frame

[port-id| aps-id]:dlci

1/1/1

aps-id: aps-1

dlci: 16

frame relay

[port-id]:dlci

1/1/1

dlci: 16

cisco-hdlc

slot/mda/port.channel

1/1/1.3

cem

slot/mda/port.channel

1/1/1.3

ima-grp

bundle-id[:vpi/vci | vpi | vpi1.vpi2]

1/1/3.1

ipcp

slot/mda/port.channel

1/2/2.4

hdlc

slot/mda/port.channel

1/1/3.1

lag-id

lag-id

lag-1

mw-link-id

mw-link-id

mw-link-1

aps-id

aps-group-id[.channel]

aps-1

bundle-id

bundle-[ima | ppp]-slot/mda.bundle-num

bundle-ima-1/1.1

tunnel-id

tunnel-<id>.[private | public]:<tag>

tunnel-1.private:1

Note:

  1. For Apipes in virtual trunking mode, vpi/vci, vpi, and vpi1.vpi2 are omitted.

Values

sap-id:

null

[port-id | bundle-id | lag-id | aps-id | mw-link-id]

dot1q

[port-id | lag-id | aps-id | mw-link-id]:qtag1

qinq

[port-id | lag-id]:qtag1.qtag2

atm

[port-id | aps-id][:vpi/vci |vpi | vpi1.vpi2]

frame

[port-id | aps-id]:dlci

cisco-hdlc

slot/mda/port.channel

cem

slot/mda/port.channel

ipcp

slot/mda/port.channel

ima-grp

bundle-id[:vpi/vci | vpi | vpi1.vpi2]

hdlc

slot/mda/port.channel

port-id

slot/mda/port[.channel]

bridge

slot/mda/bridge-id.branch-id

bridge-id 1 to 16

branch-id 1 to 32

bundle-id

bundle-type-slot/mda.bundle-num

bundle keyword

type ima, ppp

bundle-num 1 to 32

aps-id

aps-group-id[.channel]

aps keyword

group-id 1 to 24

mw-link-id

mw-link-id

id 1 to 24

lag-id

lag-id

lag keyword

id 1 to 32

qtag1

*, 0 to 4094

qtag2

*, 0 to 4094

vpi

NNI 0 to 4095

UNI 0 to 255

vci

1, 2, 5 to 65535

dlci

16 to 1022

tunnel-id

tunnel-id.[private | public]:tag

tunnel keyword

id 1 to 16 (1 is the only valid value)

tag 0 to 4094

port-id

specifies the physical port ID in the slot/mda/port format; for example, 1/2/3 specifies port 3 on MDA 2 in slot 1

The port-id must reference a valid port type. When the port-id parameter represents TDM channels, the port ID must include the channel ID. A period ‟.” separates the physical port from the channel-id. The port must be configured as an access port.

bridge-id

specifies an existing bridge that has been configured on an Integrated Services card in the slot/mda/<bridge-id.branch-id> format

bridge-id value range: 1 to 16

branch-id

specifies an existing branch that has been configured on an Integrated Services card in the slot/mda/<bridge-id.branch-id> format

branch-id value range: 1 to 32

bundle-id

specifies the multilink (PPP or IMA) bundle identifier. The bundle keyword must be entered at the beginning of the parameter. The command syntax must be configured as follows:

bundle-id: bundle-type-slot/mda.bundle-num

type: ima, ppp

bundle-num: 1 to 32

For example:

      *A:ALU-12>config# port bundle-ppp-xz5/1.1
      *A:ALU-12>config>port# multilink-bundle
qtag1, qtag2

specifies the encapsulation value used to identify the SAP on the port or subport. For dot1q encapsulation, only qtag1 is used; for qinq encapsulation, both qtag1 and qtag2 are used. If qtag1 or qtag2 is not specifically defined, the value 0 is used. The ‟*” value represents all qtag values between 0 and 4094 that are not specifically defined within another SAP context under the same port. In addition, the following qtag1.qtag2 values are invalid options:

  • *.qtag2

  • *.0

  • 0.qtag2

Values

qtag1: *, 0 to 4094

qtag2: *, 0 to 4094

The values depend on the encapsulation type configured for the interface. Port and Encapsulation Values describes the allowed values for the port and encapsulation types.

Table 19. Port and Encapsulation Values

Port Type

Encap-Type

Allowed Values

Comments

Ethernet

Null

The SAP is identified by the port.

Ethernet

Dot1q

*, 0 to 4094

The SAP is identified by the 802.1Q tag on the port. A 0 qtag1 value also accepts untagged packets on the dot1q port, and a * qtag1 value accepts any VLAN ID that is not specifically configured on the port. 1

Ethernet

QinQ

*, 0 to 4094

The SAP is identified by the two 802.1Q tags on the port. A 0 qtag1 or qtag2 value also accepts untagged packets on the qinq port, and a * qtag1 or qtag2 value accepts any VLAN ID that is not specifically configured on the port. 1

Note:

  1. Traffic matching the * qtag value uses VLAN 4095 internally.

seconds

configures the interval for each display in seconds

Values

11 to 60

Default

11

repeat

configures how many times the command is repeated

Values

1 to 999

Default

10

absolute

displays the absolute rate-per-second value for each statistic

rate

displays the rate per second for each statistic instead of the delta

sap-aggregation-group
Syntax

sap-aggregation-group group-id [interval seconds] [repeat repeat] [absolute | rate]

Context

monitor>service>id

Description

This command displays the statistics for the specified SAP aggregation group that is associated with the service.

Parameters
group-id

specifies the identifier for the SAP aggregation group

Values

1 to 32 characters

seconds

configures the interval for each display in seconds

Values

11 to 60

Default

11

repeat

configures how many times the command is repeated

Values

1 to 999

Default

10

absolute

displays the absolute rate-per-second value for each statistic

rate

displays the rate per second for each statistic instead of the delta

Output

The following output is an example of statistics for a SAP aggregation group.

Output Example
*A:SYS28# monitor service id 1570 sap-aggregation-group SAG repeat 2 
 
===============================================================================
Monitor statistics for Service 1570 SAP Aggregation Group SAG
===============================================================================
-------------------------------------------------------------------------------
At time t = 0 sec (Base Statistics)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Sap Aggregation Group Statistics
-------------------------------------------------------------------------------
Last Cleared Time     : N/A                    
 
Dropped Egress Cells (unconfigured vpi/vci): 14
 
                        Packets                 Octets
Forwarding Engine Stats (Ingress)
Dropped               : 0                       n/a                            
Off. HiPrio           : 205557                  n/a                            
Off. LowPrio          : n/a                     n/a                            
 
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio           : 0                       n/a                            
Dro. LowPrio          : n/a                     n/a                            
For. InProf           : 0                       0                              
For. OutProf          : 205557                  68605598                       
 
Forwarding Engine Stats (Egress)
Dropped               : 0                       n/a                            

Queueing Stats(Egress QoS Policy 1)
Dro. InProf           : 0                       n/a                            
Dro. OutProf          : n/a                     n/a                            
For. InProf           : 202446                  63083956                       
For. OutProf          : n/a                     n/a                            
-------------------------------------------------------------------------------
Sap Aggregation Group per Queue Stats
-------------------------------------------------------------------------------
                        Packets                 Octets
 
Ingress Queue 1 (Priority)
Off. HiPrio           : 205557                  n/a                            
Off. LoPrio           : n/a                     n/a                            
Dro. HiPrio           : 0                       n/a                            
Dro. LoPrio           : n/a                     n/a                            
For. InProf           : 0                       0                              
For. OutProf          : 205557                  68605598                       
 
Egress Queue 1
For. InProf           : 202446                  63083956                       
For. OutProf          : n/a                     n/a                            
Dro. InProf           : 0                       n/a                            
Dro. OutProf          : n/a                     n/a                            
 
-------------------------------------------------------------------------------
At time t = 11 sec (Mode: Delta)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Sap Aggregation Group Statistics
-------------------------------------------------------------------------------
Last Cleared Time     : N/A                    
 
Dropped Egress Cells (unconfigured vpi/vci): 14
 
                        Packets                 Octets
Forwarding Engine Stats (Ingress)
Dropped               : 0                       n/a                            
Off. HiPrio           : 233                     n/a                            
Off. LowPrio          : n/a                     n/a                            
 
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio           : 0                       n/a                            
Dro. LowPrio          : n/a                     n/a                            
For. InProf           : 0                       0                              
For. OutProf          : 233                     77822                          
 
Forwarding Engine Stats (Egress)
Dropped               : 0                       n/a                            

Queueing Stats(Egress QoS Policy 1)
Dro. InProf           : 0                       n/a                            
Dro. OutProf          : n/a                     n/a                            
For. InProf           : 232                     72384                          
For. OutProf          : n/a                     n/a                            
-------------------------------------------------------------------------------
Sap Aggregation Group per Queue Stats
-------------------------------------------------------------------------------
                        Packets                 Octets
 
Ingress Queue 1 (Priority)
Off. HiPrio           : 233                     n/a                            
Off. LoPrio           : n/a                     n/a                            
Dro. HiPrio           : 0                       n/a                            
Dro. LoPrio           : n/a                     n/a                            
For. InProf           : 0                       0                              
For. OutProf          : 233                     77822                          
 
Egress Queue 1
For. InProf           : 232                     72384                          
For. OutProf          : n/a                     n/a                            
Dro. InProf           : 0                       n/a                            
Dro. OutProf          : n/a                     n/a                            
 
-------------------------------------------------------------------------------
At time t = 22 sec (Mode: Delta)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Sap Aggregation Group Statistics
-------------------------------------------------------------------------------

Last Cleared Time     : N/A                    
 
Dropped Egress Cells (unconfigured vpi/vci): 14
 
                        Packets                 Octets
Forwarding Engine Stats (Ingress)
Dropped               : 0                       n/a                            
Off. HiPrio           : 232                     n/a                            
Off. LowPrio          : n/a                     n/a                            
 
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio           : 0                       n/a                            
Dro. LowPrio          : n/a                     n/a                            
For. InProf           : 0                       0                              
For. OutProf          : 232                     77488                          
 
Forwarding Engine Stats (Egress)
Dropped               : 0                       n/a                            

Queueing Stats(Egress QoS Policy 1)
Dro. InProf           : 0                       n/a                            
Dro. OutProf          : n/a                     n/a                            
For. InProf           : 233                     72696                          
For. OutProf          : n/a                     n/a                            
-------------------------------------------------------------------------------
Sap Aggregation Group per Queue Stats
-------------------------------------------------------------------------------
                        Packets                 Octets
 
Ingress Queue 1 (Priority)
Off. HiPrio           : 232                     n/a                            
Off. LoPrio           : n/a                     n/a                            
Dro. HiPrio           : 0                       n/a                            
Dro. LoPrio           : n/a                     n/a                            
For. InProf           : 0                       0                              
For. OutProf          : 232                     77488                          
 
Egress Queue 1
For. InProf           : 233                     72696                          
For. OutProf          : n/a                     n/a                            
Dro. InProf           : 0                       n/a                            
Dro. OutProf          : n/a                     n/a