Services 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).

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.

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.

Note:

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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)

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

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.

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.

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.

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

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

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.

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.

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.

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.

This section contains the following topics:

• Special QinQ SAP Identifiers

• QinQ Dot1p Match Behavior

• QinQ Top-Only Mark Option

• Maximum Number of VLAN Tags

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.

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

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.

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.

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

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#

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#

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.

*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
----------------------------------------------

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

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]

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”

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

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.

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

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

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