3.2.1. 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, 7710 SR, 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, a 7710 SR, 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, specifying the address of the source router (the 7705 SAR participating in the service communication) and 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 8-port Ethernet Adapter card, 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 on version 2 when it is in 10-port 1GigE mode. The 6-port Ethernet 10Gbps Adapter card and the 7705 SAR-X support qinq only when the card is in access 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.

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

Table 2 lists the supported pseudowire (PW) service types. The values are as defined in RFC 4446.

3.2.3. 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, Epipes, Ipipes, VPLS SAPs and SDPs (mesh and spoke), VPRN SAPs and spoke SDPs, IES SAPs and spoke SDPs, and IES in-band management SAPs.

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

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

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

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.

3.4.3. 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. Figure 2 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. Refer to the 7705 SAR OS 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:

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) 

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

1. Ethernet Encapsulations
2. SONET/SDH Encapsulations
3. TDM and Serial (TDM) Encapsulations

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.

In the case of SAPs configured on the 16-port T1/E1 ASAP Adapter card version 2, the 32-port T1/E1 ASAP Adapter card, and the 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. Refer to the 7705 SAR OS 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.

3.4.3.1.1. Ethernet Encapsulations

The following encapsulation service options are available on Ethernet ports:

1. null—supports a single service on the port; for example, where a single customer with a single service customer edge (CE) device is attached to the port.
2. dot1q—supports multiple services for one customer or services for multiple customers (see Figure 3). An example of dot1q use might 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.
3. 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 on QinQ, see QinQ Support.

Figure 3:  Multiple SAPs on a Single Port/Channel 

3.4.3.1.1.1. 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 behaves 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 behaves as a SAP on a null-encapsulated port.

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

1. 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.
2. For VPLS SAPs with STP enabled, STP listens to untagged and null-tagged BPDUs only. All other tagged BPDUs are forwarded like other customer packets. This is the same behavior as null-encapsulated ports.
3. IGMP snooping is not supported on a default SAP. By not allowing IGMP snooping of a default SAP, all IGMP packets will be transparently forwarded.
4. 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.

3.4.3.1.2. SONET/SDH Encapsulations

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

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

3.4.3.1.3. TDM and Serial (TDM) Encapsulations

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

1. atm—supports multiple services for one customer (TDM ports only)
2. 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)
3. ipcp—supports a single IP service per TDM channel group on channelized interfaces. This is 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)
4. frame-relay (TDM ports, and SDI V.35 and X.21 ports at super-rate speeds)
5. cisco-hdlc (TDM on DS1/E1 ports, and SDI V.35 and X.21 ports at super-rate speeds)
6. hdlc (TDM on DS1/E1 ports, and SDI V.35 and X.21 ports at super-rate speeds)

3.4.3.1.4. Service Types and SAP Encapsulations—Summary

Table 3 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 OS Interface Configuration Guide for more information about the cards and ports that support each of the service types.

Table 3:  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

3.4.4. 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, a 7710 SR, 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.

3.4.4.1. SDP Binding

To configure a distributed service pointing from ALU-A to ALU-B, the SDP ID on the ALU-A side (see Figure 4) 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 

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

1. Layer 2 within multiprotocol label switching (MPLS Encapsulation)
2. Layer 2 or Layer 3 within generic routing encapsulation (GRE Encapsulation)
3. Layer 2 within IP (IP Encapsulation)

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

3.4.4.4.1. MPLS Encapsulation

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

1. An MPLS 7705 SAR router supports both signaled and non-signaled LSPs through the network.
2. 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 permits 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:

1. LDP signaled
2. RSVP-TE signaled
3. user-configured (static LSP)

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

3.4.4.4.2.1. GRE Format

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

1. delivery header
2. GRE header
3. payload packet

Delivery Header

The delivery header is always an IP header.

GRE Header

The GRE header format is shown in Figure 5 and described in Table 4.

Figure 5:  GRE Header 

Table 4:  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 Figure 6 and described in Table 5.

Figure 6:  GRE Pseudowire Payload Packet over Ethernet 

Table 5:  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 on 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 on ARP, refer to the 7705 SAR OS Router Configuration Guide.

When using GRE, the service MTU might have to be set to a value smaller than 2102 octets. For more information on MTU, see MTU Settings.

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

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

Since Release 3.0, the 7705 SAR has supported the transport of pseudowires over IP tunnels. All pseudowire types supported since Release 3.0 can be transported over IP tunnels. Figure 7 shows an example of an application using Apipes over IP over Ethernet.

3.4.4.4.3.1. Payload Packet

A typical payload encapsulation format for pseudowires over IP is shown in Figure 7 and described in Table 6.

Figure 7:  IP Example of Pseudowire Payload Packet over Ethernet 

Table 6:  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 increased 1
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 on 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 on ARP, refer to the 7705 SAR OS Router Configuration Guide.

3.5.1. 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 and the 7705 SAR-M with DSL modules are ideal candidates for this scenario. They are small-scale versions 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 on the 7705 SAR-A and the 7705 SAR-M, refer to the 7705 SAR-A Chassis Installation Guide and the 7705 SAR-M Chassis Installation Guide.

Figure 8 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 over an ATM/IMA access port (SAP endpoint). An ATM SAP-to-SAP connection is set up in the 7705 SAR 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.

Figure 9 shows an example of HSDPA offload with the 7705 SAR-M using an 8-port xDSL module. Figure 10 shows an example of HSDPA offload with the 7705 SAR-M using a 6-port DSL Combination module.

Figure 9:  7705 SAR-M With 8-port xDSL Module for HSDPA Offload 

Figure 10:  7705 SAR-M With 6-port DSL Combination Module for HSDPA Offload 

On a 7705 SAR-M with an 8-port xDSL module, non-real-time UMTS traffic is backhauled over the xDSL connection and all voice traffic remains on the existing attached TDM network. For this type of network, timing recovery via DSL is typically not required as synchronization can be derived from the attached TDM network.

On a 7705 SAR-M with a 6-port DSL Combination module, non-real-time UMTS traffic is backhauled over the xDSL connection and all voice traffic is backhauled over the SHDSL interface. Using SHDSL rather than existing ATM or TDM networks as the primary means to backhaul voice and signaling is an additional step toward improving the economies of backhaul. With this functionality, all voice, signaling, and HSDPA offload can be backhauled over a low-cost DSL network. The network characteristics of SHDSL are based on the design considerations for T1/E1 lines and are subject to lower latency and delay compared with xDSL. Clock recovery with NTR is supported over both SHDSL and xDSL interfaces on the 6-port DSL Combination module and over any xDSL interface on the 8-port xDSL module.

3.5.2. Pure DSL Backhaul

There are two applications for pure backhaul over DSL:

Timing and/or synchronization are typically not requirements for deployments of the first application since mobile operators have their own cell site aggregator for timing recovery. Figure 11 shows a typical network using pure DSL backhaul with a 7705 SAR-M. Pure DSL backhaul is also supported on networks with distributed MPLS services.

Figure 11:  Pure DSL Backhaul Network Example 

Figure 12 shows a breakdown of the traffic on this network.

Figure 12:  Sample DSL Network Traffic 

In the case of pure backhaul via DSL for a mobile operator, legacy 2G and 3G traffic is aggregated at the 7705 SAR-M then fed upstream to a connected ISAM. Services remain terminated on a 7750 SR as shown in Figure 11, but without the north ATM path. Timing recovery is provided by a local GPS at the cell site, by NTR, or by 1588 for frequency synchronization.

Note: Using 1588 for timing recovery over DSL requires careful consideration of the end-to-end network characteristics for 1588v2 PTP delivery, and for the underlying PDV characteristics of the DSL used to transport the PTP packets.

Pure DSL backhaul maximizes savings for mobile operators since leased lines are not used at all. SHDSL can also be more expensive to deploy and operate because it is generally not deployed for residential broadband services. Additionally, when mobile backhaul services are combined with triple-play services reusing the same broadband platform (in this case the ISAM), the pure DSL backhaul architecture offers a compelling, cost-effective solution across a wide range of scenarios.

The pure DSL backhaul deployment model may be Layer 2-based with the use of a local Epipe on the 7705 SAR-M as shown in Figure 11. The SAP facing the ISAM must support an Epipe SAP and an IES SAP for in-band management. Alternatively, distributed services via MPLS or GRE tunnels can be used with pure DSL backhaul to offer distributed VPLS, VPRN, IES, or VLL services.

3.6.1. 802.1ag and Y.1731 Terminology

Table 8 defines 802.1ag terms. Table 9 illustrates the similarities and differences between Y.1731 and 802.1ag terms.

3.6.1.1. 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. Use MD levels to set up a messaging hierarchy for the CFM architecture.

An MA consists of a pair of maintenance endpoints (one local and one remote MEP) that are managed as part of an Ethernet VLL service. The MA and the VLL service are associated by configuring the MA bridge identifier parameter to have the same value as the VLL service ID parameter of the VLL 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 or spoke SDP. 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.

Figure 13 depicts 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 on MEP support, see Ethernet OAM.

Figure 13:  MEPs and MAs 

3.6.2. ETH-CFM Frame Format

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

Figure 14:  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 (that is, loopbacks).

Ethertype (T)

If dot1q or qinq encapsulation is not configured, then 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

This is the VLAN/dot1p identifier. If null encapsulation is configured (for Ethernet SAPs or spoke 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 details on the dot1ag or Y.1731 OAMPDU, see ETH-CFM OAMPDU.

FCS

This is the frame check sequence field.

3.6.2.1. ETH-CFM OAMPDU

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

1. MD level or MEG level: user-configured value, 0 to 7
2. version: current version is 0
3. opcodes: as defined in IEEE 802.1ag and Y.1731 standards, for messages such as:
   1. Continuity Check Message (CCM)
   2. Loopback Message (LBM)
   3. Loopback Reply (LBR)
   4. Linktrace Message (LTM)
   5. Linktrace Reply (LTR)
4. flags: as defined in IEEE 802.1ag and Y.1731 standards
5. one or more TLVs, which include:
   1. End TLV
   2. Data TLV
   3. Reply Ingress TLV
   4. Reply Egress TLV
   5. LTM egress identifier TLV
   6. LTR egress identifier TLV
   7. Test TLV

Figure 15:  ETH-CFM OAMPDU Message 

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

1. each MEG-ID must be globally unique
2. if the MEG may be required for path setup across interoperator boundaries, then the MEG-ID must be available to other network operators
3. the MEG-ID should not change while the MEG remains in existence
4. 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. Figure 16 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 16:  ICC-based MEG-ID Format 

3.6.3. ETH-CFM Functions and Tests

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

3.6.3.1. ETH-CFM Ethernet OAM Tests

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

1. loopbacks
2. linktrace
3. throughput measurement
4. continuity check
5. remote defect indication
6. alarm indication signal
7. Ethernet (signal) test

3.6.3.1.1. Loopback (LB)

The loopback 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 Figure 17, 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 message is processed. Once 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:

1. loopback message functionality on a MEP can be enabled or disabled
2. MEP—supports generating loopback messages and responding to loopback messages with loopback reply messages
3. displays the loopback test results on the originating MEP

Figure 17:  Dot1ag Loopback Test 

3.6.3.1.2. Linktrace (LT)

The linktrace 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:

1. enables/disables LT functions on an MEP
2. MEP—supports generating LTMs and responding with LTR messages
3. displays linktrace test results on the originating MEP

3.6.3.1.3. 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. Thus, 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. Note, however, that the MAC address cannot be a multicast MAC address; it must be the MEP MAC destination address (DA).

Datapath processing of LBMs is supported for the following MEPs:

1. dot1ag
   1. SAP Up MEP
   2. SAP Down MEP
   3. spoke SDP Down MEP
2. Y.1731
   1. SAP Up MEP
   2. SAP Down MEP

For spoke SDP 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), then the fastpath processing of LBMs is terminated and LBM processing continues via the CSM.

3.6.3.1.4. Continuity Check (CC)

The continuity check 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:

1. enable and disable CC for a MEP
2. automatically put local MEPs into the database when they are created
3. 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).
4. CCM transmit interval: 10ms, 100ms, 1s, 10s, 1m, 10m (default: 10s)
5. transmit interval: 10ms, 100ms, 1s, 10s, 1m, 10m (default: 10s)
6. CCM declares a fault when it:
   1. stops hearing from one of the remote MEPs for a period of 3.5 times the CC interval
   2. hears from a MEP with a lower MD level
   3. hears from a MEP that is not in the same MA
   4. hears from a MEP that is in the same MA but is not in the configured MEP list
   5. hears from a MEP that is in the same MA with the same MEP ID as the receiving MEP
   6. recognizes that the CC interval of the remote MEP does not match the local configured CC interval
   7. 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.
7. CC must be enabled in order for RDI information to be carried in the CCM OAMPDU

3.6.3.1.5. ETH-RDI

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

ETH-RDI has the following two applications:

1. 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.
2. 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:

1. MEG level—the MEG level at which the MEP exists
2. ETH-RDI transmission period—application-dependent and is the same value as the ETH-CC transmission period
3. 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.

3.6.3.1.6. ETH-AIS

The Ethernet Alarm Indication Signal function (ETH-AIS) 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 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:

1. signal failure conditions in the case where ETH-CC is enabled
2. 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. Once the AIS condition is cleared, a MEP resumes alarm generation upon detecting defect conditions.

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

1. client MEG level—the MEG level at which the most immediate client layer MEPs exist
2. ETH-AIS transmission period—the transmission period of frames with ETH-AIS information
3. priority—the priority of frames with ETH-AIS information

3.6.3.1.7. ETH-Test

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

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 MEP requires the following configuration information:

1. MEG level—the MEG level at which the MEP exists
2. unicast MAC address—the unicast MAC address of the peer MEP for which ETH-Test is intended
3. 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.
4. priority—the priority of frames with ETH-Test information

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

3.6.4. MEP Support (802.1ag and Y.1731)

The 7705 SAR supports Up and Down maintenance association endpoints (MEPs) on Ethernet SAPs for both 802.1ag and Y.1731. It also supports Down MEPs on Ethernet spoke SDPs for 802.1ag only.

3.6.4.1. 802.1ag MEP Support on Ethernet SAPs

The 7705 SAR supports Up and Down MEPs on Ethernet SAPs. Figure 18 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 towards port A.

Figure 18:  MEP on Ethernet Access 

Figure 19 shows how a Down MEP on an Ethernet SAP might 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 Figure 19, separate dot1ag instances initiated on the 9500 MPR 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 19:  Down MEP at Ethernet SAP 

3.6.4.2. 802.1ag MEP Support on Ethernet Spoke SDPs

The 7705 SAR supports down maintenance association endpoints (MEPs) on Ethernet spoke SDP endpoints. Figure 20 illustrates a 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.

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

1. termination of the CFM messages destined for the MEP-ID of the 7705 SAR
2. termination of CFM messages at the user-configured domain only
3. discarding of OAMPDUs at a lower MD level than the configured one (an alarm message is raised)
4. transparent pass-through of upper layer CFM messages
   1. 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. Only Down MEP functionality is supported on Ethernet spoke SDPs (that is, termination of CFM messages that are ingress from the Ethernet PW, or generation of CFM packets that are destined for the 7750 SR spoke SDP MEP-ID).

Figure 20:  Dot1ag Down MEPs on Spoke SDPs 

In Figure 20, assuming that the MEP is enabled both on the 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 SR node. The Ethernet PW running between the 7705 SAR and the SR generates a pipe-like connectivity; thus, 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 SR and 7705 SAR endpoints.

3.6.4.3. Y.1731 MEP Support on Ethernet SAPs

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

Figure 21 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 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 SDP is on the network side. If a spoke SDP Down MEP is used, packets are terminated and extracted on the network side without being switched through the switching fabric.

Figure 21:  Y.1731 MEP Support on the 7705 SAR 

3.6.5. Priority Mapping (802.1ag and Y.1731)

Operators often run OAM tests over a single, specific forwarding class (FC). For example, an operator might 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. Thus, 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.

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

3.7.1. 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 Figure 22. 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 22:  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:

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

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

Note: QinQ is not supported by DSL and GPON modules on the 7705 SAR-M.

Figure 23 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 23:  QinQ Tagging Example 

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

3.7.2.2. 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 might occur in the scenario shown in Figure 24, where VPLS QinQ SAPs with force-c-vlan-forwarding enabled connect Customer 1 and Customer 2 and preserve the ingress VLAN tag.

Figure 24:  QinQ Using VPLS Ethernet SAPs 

In Figure 24, the following events occur.

1. 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.
2. 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:
   1. removes the first (top) tag
   2. replaces the second (middle) tag
   3. replaces only the Ethertype of the third (bottom/innermost) tag (that is, the VLAN ID is not replaced)

3.7.2.3. Example 3: QinQ Using VPLS with ATM SAPs

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

Figure 25:  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.

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

3.7.3.1. Special QinQ SAP Identifiers

Table 12 describes the special SAP identifiers used on the 7705 SAR. In Table 12, 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 12:  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.*	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  2

Notes:

1. qtag1 is the top (outer) tag. qtag2 is the bottom (inner) tag.
2. 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 Table 12 process frames. Packet breakdowns are described in Raw and Tagged Modes.

1. default SAP (port-id:qtag1.*)
   1. receives all frames with an explicit outer tag value of qtag1, regardless of the inner tag
   2. the outer tag is stripped and the inner tag is passed transparently
   3. 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.
2. null SAP (port-id:0.*)
   1. receives all untagged frames and/or any frames with a VLAN tag of 0
   2. 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.
3. null inner SAP (port-id:qtag1.0)
   1. receives all frames with explicit outer tag value qtag1, and may have an inner tag of 0 or no inner tag at all
   2. 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”.
4. invalid SAPs (not supported) (port-id:*.qtag2 and port-id:*.0)

3.7.4. QinQ Configuration Overview

The basic steps to configure QinQ are as follows.

3.9.1. Reference Sources

For information on standards and supported MIBs, refer to Standards and Protocol Support.