How Layer 2 Services over MPLS Work
When layer 2 services are configured over MPLS, layer 2 traffic is encapsulated in MPLS frames and sent over MPLS tunnels. A virtual circuit (VC) label that indicates a specific layer 2 connection, such as a Frame Relay data-link connection identifier (DLCI), is pushed into the label stack between the tunnel label and the layer 2 data.
A service-specific control word may be placed between the layer 2 data and the VC label. The control word is used for frame sequencing and carrying service-specific information, such as Frame Relay forward explicit congestion notification (FECN) and backward explicit congestion notification (BECN) information. At the tunnel end, the VC label is used to find the layer 2 interface over which the traffic is sent. The control word, if present, is used to convert the encapsulated layer 2 traffic into its native format.
Because MPLS labels are unidirectional, two VC labels are required for each layer 2 connection. The VC labels are distributed by the Label Distribution Protocol (LDP) in downstream-unsolicited (DU) mode between the two routers. The layer 2 connection status signaling may be emulated by advertising and withdrawing the VC labels. For example, if the Frame Relay subinterface between customer premises equipment (CPE) and a provider edge (PE) router goes down, the corresponding VC label is withdrawn by the PE router. When the remote PE router at the other end receives the label withdrawal, it translates the label withdrawal into LMI notifications to its CPE. When the Frame Relay subinterface comes back, a VC label is advertised, and the remote PE router again translates it into LMI notifications.
Local Cross-Connects Between Layer 2 Interfaces Using MPLS
You can configure layer 2 services over MPLS to transmit data between two layer 2 interfaces that reside on the same E-series router. In this configuration, which is referred to as a local cross-connect, traffic that arrives at the router's ingress interface is switched out the egress interface, instead of going through an MPLS core network.
A local cross-connect enables the router to function as a layer 2 switch. It operates with any of the supported layer 2 services listed in Overview.
To configure local cross-connects, you must use the mpls-relay command. For a configuration example that shows how to create local cross-connects between Ethernet/VLAN interfaces, see Configuring Local Cross-Connects Between Ethernet/VLAN Interfaces.
MPLS Shim Interfaces
An MPLS shim interface is stacked on a layer 2 interface to do either of the following:
- Create a layer 2 circuit by cross-connecting the layer 2 interface to an LSP corresponding to the VC label.
- Create a local cross-connect by cross-connecting the layer 2 interface to another layer 2 interface.
You can create or remove MPLS shim interfaces with the mpls-relay or route interface commands. Shim interfaces are also created in or removed implicitly from a load-balancing group by the member interface command when you configure the group; see CE-Side Load Balancing for Martini Layer 2 Transport for more information. Each MPLS shim interface exists in a particular virtual router.
Each MPLS shim interface points to a single MPLS next hop. When layer 2 frames arrive on the layer 2 interface below the MPLS shim interface, they are encapsulated in an MPLS packet and forwarded to that MPLS next hop. The details of the encapsulation are determined by the attributes of the shim interface.
The MPLS next hop to which the shim interface points is set by an MPLS signaling protocol, which adds a special entry with implicit null in label to the interface label-space MPLS forwarding table of the shim interface. For traffic arriving from the core, the MPLS signaling protocol adds a normal entry with a real in label to the platform label-space MPLS forwarding table whose next hop points to the MPLS shim interface.
You can configure the following attributes for each MPLS shim interface:
- The administrative state, enabled or disabled, configured with the mpls-relay disable command.
- The IP address of the remote PE router for the layer 2 circuit, configured with the mpls-relay command. The shim interface is cross-connected to an LSP corresponding to the VC label received from the specified remote PE router, or to another shim interface in the local cross-connects case. For local cross-connects the IP address is local to the PE router.
- The name of an RSVP-TE base tunnel to be used for the layer 2 circuit, configured with the route interface command.
- The group ID of the shim interface, configured using the group-id option of the mpls-relay and route interface commands. Even though you can configure the group ID, the JUNOSe software does not currently use it.
- Whether the control word is used, configured with the control-word and no-control-word options of the mpls-relay and route interface commands. The layer 2 interface determines the default preference if this option is not configured. Some layer 2 interfaces require a control word; others do not support it.
- Whether sending nonzero sequence numbers in the control word is preferred, configured with the sequencing and no-sequencing options of the mpls-relay and route interface commands. The layer 2 interface determines the default preference if this option is not configured. Even when preferred, the sequence numbers might not be sent if the control word is not used due to configuration. You can only configure whether the numbers are sent. MPLS always accepts zero sequence numbers and checks the order of nonzero sequence numbers in received MPLS packets that are forwarded to an MPLS shim interface. Out-of-order packets are discarded.
- The number of the load-balancing group of which the shim interface is a member. This attribute is set to the current load-balancing group when the shim interface is implicitly created with the member interface command. See CE-Side Load Balancing for Martini Layer 2 Transport for more information.
You can enable statistics collection for the MPLS shim interfaces. See Monitoring Layer 2 Services over MPLS for more information.
Multiservice with Layer 2 Services
When you configure an MPLS shim interface over an ATM, Frame Relay, or HDLC layer 2 interface, no other interface (for example, PPP or IP) can be stacked above the layer 2 interface.
By contrast, when you configure an MPLS shim interface over any Ethernet or Ethernet/VLAN interface, both the MPLS shim interface and other interfaces (such as IP, PPP, or PPPoE) can be stacked above the layer 2 interface.
When you configure both an MPLS shim interface and another interface over a layer 2 interface, traffic for a protocol explicitly configured in the interface stack is forwarded to that protocol layer for further processing. Traffic for any nonconfigured protocols is forwarded to the MPLS shim interface on the other side of the connection.
When the MPLS shim interface is the only layer stacked above the layer 2 interface, as is the case with ATM, Frame Relay, and HDLC, then all traffic is forwarded to the MPLS shim interface and across the MPLS tunnel.
ATM Layer 2 Services
ATM layer 2 services over MPLS provide ATM switch-like functionality for E-series routers. This feature is useful for customers who run IP in the majority of their network but still have to carry a small amount of non-IP traffic, as in the example shown in Figure 27.
In this scenario, it is not economical to have special ATM switches in front of E-series routers just to accommodate the small percentage of non-IP traffic. The ATM layer 2 services over MPLS feature lets you replace the ATM traffic selector switch with an E-series router, as shown in Figure 28. The two routers pass traffic between two interfaces through an MPLS tunnel using Martini encapsulation, regardless of the contents of the packets.
ATM layer 2 services over MPLS supports two encapsulation methods on E-series routers:
The following sections describe each of these encapsulation methods.
AAL5 Encapsulation
JUNOSe software supports the AAL5 relay method of encapsulation that is specified in the Martini draft, Encapsulation Methods for Transport of ATM Over MPLS Networks—draft-ietf-pwe3-atm-encap-07.txt (April 2005 expiration). This method is also referred to as AAL5 service data unit (SDU) encapsulation.
ATM Martini encapsulation emulates ATM switch behavior by creating a pseudowire between pairs of ATM virtual circuits. When the router receives AAL5 packets on one of those circuits, it reassembles them, encapsulates them using Martini encapsulation, and forwards them to an MPLS tunnel. At the end of the tunnel, the packet is de-encapsulated, segmented back, and sent to a selected ATM VC.
In Figure 29, an MPLS tunnel connects two E-series routers, and ATM cross-connects provide a pseudowire between the ATM VCs on the two routers. All AAL5 packets on the pseudowire are encapsulated. The egress VC does not need the same ATM address as the ingress circuit.
To use AAL5 SDU encapsulation, you must use the aal5all encapsulation keyword when you configure ATM subinterfaces. For configuration examples, see Configuring Local ATM Cross-Connects with AAL5 Encapsulation.
OAM Cells
The E-series router performs a similar operation for Operation, Administration, and Maintenance (OAM) cells, except that they do not need reassembly.
The router passes the following OAM cells transparently:
- F5 alarm indication signal (AIS) segment and end-to-end
- F5 remote defect indication (RDI) segment and end-to-end
- F5 loopback segment and end-to-end
- Resource management
- F5 continuity check segment and end-to-end
In addition, F4 OAM cell forwarding is supported.
JUNOSe software does not allow for setting a segment endpoint on an ATM cross-connect interface. Segment OAM cells are forwarded to the egress interface in the same manner as end-to-end cells.
QoS Classification
Packets are subject to normal quality of service (QoS) classification according to service categories assigned to ATM virtual circuits that make up the connection.
Limitations
The JUNOSe implementation of the Martini draft has the following limitations:
- Only AAL5 packets and OAM cells are forwarded.
- There is no equivalent of VP switching.
- Point-to-multipoint connections are not supported.
- Automatic connection setup using user-to-network interface (UNI) signaling and private network-to-network interface (PNNI) is not supported.
- The ATM MIB cross-connected table is not supported.
- Connections between ATM circuits and non-ATM interfaces are not supported.
Control Word Support
Martini draft encapsulation includes a control word with the following fields:
- T bit for transport type
- E bit for explicit forward congestion indication (EFCI)
- C bit for cell loss priority (CLP)=1 indication
- U bit for command/response indication based on AAL5 common part convergence sublayer user-to-user indication (CPCS-UU)
- Optional sequence number
The current JUNOSe implementation supports the T bit and optional sequence number fields.
VCC Cell Relay Encapsulation
E-series routers support virtual channel connection (VCC) cell relay encapsulation for ATM layer 2 services over MPLS. VCC cell relay encapsulation, like AAL5 encapsulation, is defined in the Martini draft, Encapsulation Methods for Transport of ATM Over MPLS Networks—draft-ietf-pwe3-atm-encap-07.txt (April 2005 expiration).
VCC cell relay encapsulation enables a router to emulate ATM switch behavior by forwarding individual ATM cells over an MPLS pseudowire (also referred to as an MPLS tunnel) created between two ATM VCCs, or as part of a local ATM cross connect between two ATM 1483 subinterfaces on the same router. The JUNOSe implementation conforms to the required N-to-1 cell mode encapsulation method described in the Martini draft, with the provision that only a single ATM virtual circuit (VC) can be mapped to an MPLS pseudowire.
VCC cell relay encapsulation is useful for voice-over-ATM applications that use ATM Adaptation Layer 2 (AAL2)-encapsulated voice transmission.
For configuration instructions, see Configuring an MPLS Pseudowire with VCC Cell Relay Encapsulation.
AAL0 Raw Cell Mode
VCC cell relay encapsulation supports ATM Adaptation Layer 0 (AAL0) encapsulation, also referred to as raw cell mode or null encapsulation. AAL0 is often used to carry signaling ATM cells, which the router treats as raw cells.
When you create an ATM PVC as part of a VCC cell relay configuration, you must use the aal0 encapsulation.
Cell Concatenation Parameters
VCC cell relay encapsulation supports the concatenation (aggregation) of multiple ATM cells in a single encapsulated packet that is transmitted on the MPLS pseudowire.
You can use the atm cell-packing and atm mcpt-timers commands to configure the following parameters that control how the router performs cell concatenation:
- Maximum number of ATM cells that the router can concatenate in a single packet.
- Values (in microseconds) for each of the three ATM Martini cell packing timers maintained on the router. These timers define the time threshold that the router uses to concatenate ATM cells and transmit the cells in an MPLS packet on the pseudowire.
- Numeric identifier (1, 2, or 3) that indicates which of the three ATM Martini cell packing timers you want to use to detect timeout of the cell collection threshold.
Based on this configuration, the router attempts to concatenate the specified maximum number of ATM cells into an MPLS packet within the time interval allowed by the ATM Martini cell packing timer you selected. When the timer detects that the allotted time interval has expired, the router forwards the MPLS packet even if it contains fewer than the specified maximum number of aggregated cells per packet.
Cell Concatenation and Latency
Cell concatenation increases network latency, which is undesirable for voice-over-ATM applications. To minimize these effects, use care in choosing values for the ATM Martini cell packing timers.
We recommend that for voice-over-ATM configurations, you select timeout values between 6 microseconds and 3 x 6 microseconds. Values within this range are generally low enough to maintain a reasonable cell delay and high enough to take advantage of the cell concatenation mechanism.
If traffic shaping is enabled on the egress router, the JUNOSe implementation of VCC cell relay encapsulation preserves the spacing between cells.
Control Word Support
VCC cell relay encapsulation requires use of a control word. The control word contains the T, E, C, and U bits, as well as an optional sequence number field, as described in Control Word Support.
The JUNOSe implementation of VCC cell relay encapsulation supports the T bit, which is always set to indicate raw ATM cells, and the optional sequence number. The E, C, and U bits have no meaning for VCC cell relay configurations because the router forwards a complete ATM cell with as much header information as possible.
Unsupported Features
VCC cell relay encapsulation on JUNOSe routers does not support the following features:
- Mapping multiple ATM VCs to a single MPLS pseudowire
- Optional Martini one-to-one cell encapsulation method with cell headers removed
HDLC Layer 2 Services
E-series routers support the creation of HDLC layer 2 circuits across an MPLS network. An HDLC layer 2 circuit can carry any standard HDLC traffic (including PPP) or Cisco HDLC traffic between two CE devices across an MPLS network. In an HDLC layer 2 circuit configuration, an E-series router functions as one of the PE routers.
You can configure an HDLC layer 2 circuit between two serial interfaces, between two packet over SONET (POS) interfaces, or between a serial interface and a POS interface. The interfaces at either end of the circuit can operate at the same speed or at different speeds. For example, you can configure an HDLC layer 2 circuit between a serial interface on a T1 circuit and a POS interface on an OC3 circuit.
For configuration instructions, see Configuring HDLC Layer 2 Services.
Interface Stacking
When you configure an MPLS shim interface above an HDLC layer 2 interface, which is in turn stacked above a serial or POS interface, no other interfaces (for example, PPP) can be stacked above the HDLC interface. In other words, the HDLC interface can have only one upper interface.
In practice, this means that you cannot issue the mpls-relay command (to create the HDLC layer 2 circuit) and then issue an encapsulation command (such as encapsulation ppp) for the same HDLC interface. If you attempt to do so, the router prevents the configuration and displays an error message.
This behavior contrasts with that of bridged Ethernet and Ethernet interfaces (with and without VLANs), which allow configuration of both an MPLS shim interface and another interface (such as IP, PPP, or PPPoE) above the layer 2 interface.
Encapsulation
The JUNOSe implementation of HDLC layer 2 circuits supports encapsulation of either HDLC frames or PPP frames within MPLS frames. By default, the router uses VC-type HDLC signaling and HDLC encapsulation to encapsulate HDLC frames in MPLS.
However, if you want the router to encapsulate PPP frames directly in MPLS without the HDLC header, you can include the optional relay-format ppp keywords in the mpls-relay or route interface command to cause the router to use VC-type PPP signaling and PPP encapsulation instead of the default VC-type HDLC signaling and HDLC encapsulation. This option, which is available only for serial and POS interfaces, is useful if the traffic carried on the serial or POS interface contains actual PPP packets and not, for example, Cisco HDLC packets.
Control Word Support
The router always sends a control word for HDLC layer 2 circuits, regardless of whether or not sequencing is enabled.
Local Cross-Connects
You can configure an HDLC layer 2 circuit in a local cross-connect configuration between serial or POS interfaces within the same router. In this configuration, the pairs of HDLC interfaces are directly cross-connected to each other. The cross-connected interfaces can be different types and operate at different speeds; for example, you can cross-connect a serial interface on a T1 circuit and a POS interface on an OC3 circuit.