Packet Pseudowire Encapsulation over an MPLS PSN
draft-bryant-pwe3-packet-pw-02.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 24, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document describes a pseudowire that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. For correct operation these clients require a multi-protocol interface with fate sharing between the client protocol suite. The packet pseudowire may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
2.  Network Reference Model
3.  Forwarding Model
4.  The Protocol Identifier Label
5.  Encapsulation
6.  Packet Pseudowire Control Word
7.  Signaling the PID Label
    7.1.  The Protocol FEC Element
    7.2.  Procedures to distribute the PID FEC.
8.  Status Indication
9.  Setting the load balance label
10.  Client Network Layer Model
11.  Congestion Considerations
12.  Security Considerations
13.  IANA Considerations
14.  Acknowledgements
15.  References
    15.1.  Normative References
    15.2.  Informative References
§  Authors' Addresses

1.  Introduction

There is a need to provide a method of carrying a packet service over an MPLS PSN in a way that provides isolation between the two networks. The server MPLS network may be an MPLS network or a network conforming to the MPLS-TP [RFC5317] (Bryant, S. and L. Andersson, “Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile,” February 2009.). The client may also be either a MPLS network of a network conforming to the MPLS-TP. Considerations regarding the use of an MPLS network as a server for an MPLS-TP network are outside the scope of this document.

Where the client equipment is connected to the server equipment via physical interface, the same data-link type MUST be used to attach the clients to the Provider Edge equipments (PE)s, and a pseudowire (PW) of the same type as the data-link MUST be used [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.). The reason that inter-working between different physical and data-link attachment types is specifically disallowed in the pseudowire architecture is because this is a complex task and not a simple bit-mapping exercise. The inter-working is not limited to the physical and data-link interfaces and the state-machines. It also requires a compatible approach to the formation of the adjacencies between attached client network equipment. As an example the reader should consider the differences between router adjacency formation on a point to point link compared to a multi-point to multi-point interface (e.g. Ethernet).

A further consideration is that two adjacent MPLS LSRs do not simply exchange MPLS packets. They exchange IP packets for adjacency formation, control, routing, label exchange, management and monitoring purposes. In addition they may exchange data-link packets as part of routing (e.g. IS-IS hellos and IS-IS LSPs) and for OAM purposes such as Link Layer Discovery protocol [IEEE standard 802.1AB-2009]. Thus the two clients require an attachment mechanism that can be used to multiplex a number of protocols. In addition it is essential to the correct operation of the network layer that all of these protocols fate share.

Where the client LSR and server PE is co-located in the same equipment, the data-link layer can be simplified to a simple protocol identifier (PID) that is used to multiplex the various data-link types onto a pseudowire. This is the method that described in this document.

2.  Network Reference Model

The network reference model for the packet pseudowire operating in an MPLS network is shown in Figure 1. This is an extension of Figure 3 "Pre-processing within the PWE3 Network Reference Model" from [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.).

               PW                            PW
            End Service                   End Service
                |                            |
                |<------- Pseudowire ------->|
                |                            |
                |          Server            |
                |     |<- PSN Tunnel ->|     |
                |     V                V     |
-------   +-----+-----+                +-----+-----+   -------
       )  |     |     |                |     |     |  (
client  ) | MPLS| PE1 |      PW1       | PE2 | MPLS| ( Client
MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN
        ) |     |     |                |     |     | (
       )  |     |     |================|     |     |  (
-------   +-----+-----+                +-----+-----+   --------
                ^                            ^
                |                            |
                |                            |
                |<---- Emulated Service----->|
                |                            |
         Virtual physical             Virtual physical
            termination                  termination

MPLS Pseudowire Network Reference Model

In this model LSRs, LSR1 and LSR2, are part of the client MPLS packet switched network (PSN). The PEs, PE1 and PE2 are part of the server PSN, that is to be used to provide connectivity between the client LSRs. The attachment circuit that is used to connect the MPLS LSRs to the PEs is a virtual interface within the equipment. A packet pseudowire is used to provide connectivity between these virtual interfaces. This packet pseudowire is used to transport all of the required layer 2 and layer 3 between protocols between LSR1 and LSR2.

3.  Forwarding Model

The packet PW forwarding model is illustrated in Figure 2. The forwarding operation can be likened to a virtual private network (VPN), in which a forwarding decision is first taken at the client layer, an encapsulation is applied and then a second forwarding decision is taken at the server layer.

         +------------------------------------------------+
         |                                                |
         |  +--------+                        +--------+  |
         |  |        |   Pkt   +-----+        |        |  |
      ------+        +---------+ PW1 +--------+        +------
         |  | Client |    AC   +-----+        | Server |  |
  Client |  | LSR    |                        | LSR    |  | Server
 Network |  |        |   Pkt   +-----+        |        |  | Network
      ------+        +---------+ PW2 +--------+        +------
         |  |        |    AC   +-----+        |        |  |
         |  +--------+                        +--------+  |
         |                                                |
         +------------------------------------------------+

Packet PW Forwarding Model

A packet PW PE comprises three components, the client LSR, PW processor and a server LSR. Note that [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.) does not formally indicate the presence of the server LSR because it does not concern itself with the server layer. However it is useful in this document to recognise that the server LSR exists.

It may be useful to first recall the operation of a layer two PW such as an Ethernet PW [RFC4448] (Martini, L., Rosen, E., El-Aawar, N., and G. Heron, “Encapsulation Methods for Transport of Ethernet over MPLS Networks,” April 2006.) within this model. The client LSR is not present and packets arrive directly on the attachment circuit (AC) which is part of the client network. The PW undertakes any header processing, if configured to do so, it then pushes the PW control word (CW), and finally pushes the PW label. The PW function then passes the packet to the LSR function which pushes the label needed to reach the egress PE and forwards the packet to the next hop in the server network. At the egress PE, the packet typically arrives with the PW label at top of stack, the packet is thus directed to the correct PW instance. The PW instance performs any required reconstruction using, if necessary, the CW and the packet is sent directly to the attachment circuit.

Now let us consider the case client layer MPLS traffic being carried over a packet PW. An LSR belonging to the client layer is embedded within the PE equipment. This is a type of native service processing element [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.). This LSR determines the next hop in the client layer, and pushes the label needed by the next hop in the client layer. It then passes the packet to the correct PW instance indicating the packet protocol type. If the PW is configured to require a CW this is pushed. The PW instance then examines the protocol type and pushes a label that identifies the protocol type to the egress PE. The PW instance then proceeds as it would for a layer two PW, by pushing the PW label and then handing the packet to the server layer LSR for delivery. At egress, the packet again arrives with the PW label at the top of stack which causes the packet to be passed to the correct PW instance. This PW instance knows that the PW type is a packet PW, and hence that it needs to interpret the next label as a protocol type identifier. If necessary the CW is then popped and processed. The packet is then passed to the egress client LSR together with information that identifies the packet protocol type. The egress client LSR then forwards the packet in the normal manner for a protocol of that type.

Note that although the description above is written in terms of the behaviour of an MPLS LSR, the processing model would be similar for an IP packet, or indeed any other protocol type.

Note that the semantics of the PW between the client LSRs is a point to point link.

4.  The Protocol Identifier Label

Protocol identifier labels (PIDLs) are allocated by the egress PE. One PIDL is required for each unique protocol type that the egress PE must forward to its client LSRs. PIDLs MUST be allocated from the per-platform label space. PIDLs MUST NOT be reserved labels. The mapping between protocol type and PIDL is either signaled to the ingress PE using the procedure described in Section 7 (Signaling the PID Label), or is configured at the ingress PE.

5.  Encapsulation

The Protocol Stack Reference Model for a packet PW is shown in Figure 3 (PWE3 Protocol Stack Reference Model) below

   +-------------+                                +-------------+
   |  Client     |                                |  Client     |
   |  network    |                                |  network    |
   |  layer      |         Client Service         |  layer      |
   |  service    |<==============================>|  service    |
   +-------------+            Pseudowire          +-------------+
   |Demultiplexer|<==============================>|Demultiplexer|
   +-------------+                                +-------------+
   |   Server    |                                |   Server    |
   |    PSN      |            PSN Tunnel          |    PSN      |
   |   MPLS      |<==============================>|   MPLS      |
   +-------------+                                +-------------+
   |  Physical   |                                |  Physical   |
   +-----+-------+                                +-----+-------+

The corresponding packet PW encapsulation is shown in Figure 4 (Encapsulation of a pseudowire with a pseudowire load balancing label).

   +-------------------------------+
   |            Client             |
   |          Network Layer        |
   |            packet             |  n octets
   |                               |
   +-------------------------------+
   |    Optional Control Word      |  4 octets
   +-------------------------------+
   |        PID Label (S=1)        |  4 Octets
   +-------------------------------+
   |          PW label             |  4 octets
   +-------------------------------+
   |   Server MPLS Tunnel Label(s) |  n*4 octets (four octets per label)
   +-------------------------------+

Where the CW is not used another method is needed to multiplex PW OAM into the PW. This can be accomplished using one of the methods described in [RFC5085] (Nadeau, T. and C. Pignataro, “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” December 2007.), or by using an ACH indicated using a generic alert label [RFC5586] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.).

The setting the TTL of an MPLS label is a matter of local policy on a PE. However when sending the PID label the TTL SHOULD be set to 1 to avoid forwarding a mis-routed packet beyond the first PE receiving it.

6.  Packet Pseudowire Control Word

The packet pseudowire control word (CW) is optional.

Where the CW is used, it conforms to the preferred pseudowire MPLS control word defined by Figure 2 of [RFC4385] (Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN,” February 2006.). For reference the packet pseudowire control word is shown in Figure 5. The definitions of the fragmentation (FRG), length and sequence number fields are to be found in [RFC4385] (Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN,” February 2006.).

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |FRG|  Length   | Sequence Number               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Packet Pseudowire Control Word

7.  Signaling the PID Label

To signal the label binding between an MPLS label, and the desired PIDL the new Label Distribution protocol (LDP) Forwarding Equivalence Class (FEC) element is defined below is used.

7.1.  The Protocol FEC Element

To distribute the PID FEC we define a new FEC element containing the PID number. This is shown in Figure 6.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Prot (0x83) |   Reserved    |         Protocol type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LDP PID FEC Element

Where

7.2.  Procedures to distribute the PID FEC.

The LDP procedures defined in [RFC5036] (Andersson, L., Minei, I., and B. Thomas, “LDP Specification,” October 2007.) are used to distribute the PID label binding to the protocol ID type. The LDP liberal label retention independent mode is used to distribute the PID label bindings, however the LDP Label request procedures MUST also be supported for the PID label FEC as required by [RFC5036] (Andersson, L., Minei, I., and B. Thomas, “LDP Specification,” October 2007.). Once a Protocol FEC label mapping is advertised by a PE, it will be used for all packet PWs that require that protocol. A PE MUST mark a local virtual interface as faulted if the PE has not received a remote label binding for a protocol that is configured on the interface. Similarly, if a label withdraw is received for a particular protocol, all virtual interfaces using packet PWs that have that specific protocol configured MUST receive the appropriate fault condition. This FEC MUST only be used in conjunction with the packet PW, and MPLS packets containing only the advertised MPLS label MUST NOT be sent to the PE that advertised this FEC. The use of this FEC element without the packet PW label is undefined.

8.  Status Indication

A pseudowire status indicating a fault can be considered equivalent to interface down and SHOULD be passed across the virtual interface to the local LSR. This improves scaling in PE with large numbers of co-resident LSRs and with LSRs that have large numbers of interfaces mapped to pseudowires.

The mechanism described for the mapping of pseudowire status to the virtual interface state that are described in [RFC4447] (Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),” April 2006.) and in section 10 of [I‑D.ietf‑pwe3‑segmented‑pw] (Martini, L., Nadeau, T., Metz, C., Bocci, M., Aissaoui, M., Balus, F., and M. Duckett, “Segmented Pseudowire,” April 2010.) apply to the packet pseudowire. Pseudowire status messages indicating pseudowire or remote virtual interface faults MUST be mapped to a fault indication on the local virtual interface.

9.  Setting the load balance label

The client service may wish the packet PW to take advantage of any Equal Cost Multi-Path (ECMP) support in the server layer. In this case a load balance label as described in [I‑D.ietf‑pwe3‑fat‑pw] (Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, “Flow Aware Transport of Pseudowires over an MPLS PSN,” January 2010.) may be included in the MPLS label stack. Indeed without this feature there will be significant polarization of the traffic in the network, since most of the client traffic will be either MPLS or IP and therefore most of the traffic between a pair of PEs will be carried with the same pair of bottom of stack labels. The FAT label must be inserted at the bottom of stack, i.e. below the PIDL as shown in Figure 7 (Encapsulation of a pseudowire with a pseudowire load balancing label).

   +-------------------------------+
   |            Client             |
   |          Network Layer        |
   |            packet             |  n octets
   |                               |
   +-------------------------------+
   |    Optional Control Word      |  4 octets
   +-------------------------------+
   |        FAT Label (S=1)        |  4 octets
   +-------------------------------+
   |        PID Label (S=0)        |  4 Octets
   +-------------------------------+
   |          PW label             |  4 octets
   +-------------------------------+
   |   Server MPLS Tunnel Label(s) |  n*4 octets (four octets per label)
   +-------------------------------+

Where the client service is MPLS it would be appropriate to copy the client layer, bottom of stack MPLS label into the FAT label. Where the client layer is IP the FAT label would typically be calculated by hashing on the source and destination addresses, the protocol ID and higher-layer flow-dependent fields such as TCP/UDP ports, L2TPv3 Session ID’s etc.

The exact specification of the method of selecting an appropriate load balance label value is outside the scope of this document.

10.  Client Network Layer Model

The packet PW appears as a single point to point link to the client layer. Network Layer adjacency formation and maintenance between the client equipments will the follow normal practice needed to support the required relationship in the client layer. The assignment of metrics for this point to point link is a matter for the client layer. In a hop by hop routing network the metrics would normally be assigned by appropriate configuration of the embedded client network layer equipment (e.g. the embedded client LSR). Where the client was using the packet PW as part of a traffic engineered path, it is up to the operator of the client network to ensure that the server layer operator provides the necessary service layer agreement.

11.  Congestion Considerations

This pseudowire is normally used to carry IP, MPLS and their associated support protocols over an MPLS network. There are no congestion considerations beyond those that ordinarily apply to an IP or MPLS network. Where the packet protocol being carried is not IP or MPLS and the traffic volumes are greater than that ordinarily associated with the support protocols in an IP or MPLS network, the congestion considerations being developed for PWs apply [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.), [I‑D.ietf‑pwe3‑ms‑pw‑arch] (Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge,” July 2009.).

12.  Security Considerations

The packet pseudowire provides no means of protecting the contents or delivery of the pseudowire packets on behalf of the client packet service. The packet pseudowire may, however, leverage security mechanisms provided by the MPLS Tunnel Layer. A more detailed discussion of pseudowire security is given in [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.), [RFC4447] (Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),” April 2006.) and [RFC3916] (Xiao, X., McPherson, D., and P. Pate, “Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3),” September 2004.).

The Protocol FEC, and corresponding label is only used in the context of a packet PW, and it does not change the security implications already discussed in [RFC4447] (Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),” April 2006.).

13.  IANA Considerations

Editor's note - the text below was provided to me but I cannot see the reservation in the registry.

A FEC element allocation of 0x83 has already be made by IANA. However, IANA are requested to up date the registry "Forwarding Equivalence Class (FEC) Type Name Space" with a reference to this RFC number once the number is allocated.

14.  Acknowledgements

The authors acknowledge the contribution make by Sami Boutros, Giles Herron, Siva Sivabalan and David Ward to this document.

15.  References

15.1. Normative References

15.2. Informative References

Authors' Addresses