Packet Pseudowire Encapsulation over an MPLS PSN
draft-bryant-pwe3-packet-pw-00.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 August 31, 2009.

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.  Packet Pseudowire Control Word
4.  Status Indication
5.  Congestion Considerations
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.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 a "classic" MPLS network or an MPLS-TP network [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 "classic" MPLS network of an MPLS-TP network. Considerations as to whether an MPLS "classic" network can act 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 to attach the clients to the PEs, and a pseudowire 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 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 (e.g. Cisco Discovery Protocol). 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 LSRs and server PEs are 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 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.  Packet Pseudowire Control Word

This section describes the encapsulation of a packet pseudowire. The packet pseudowire always uses the control word. The control word consists of two components: the preferred pseudowire MPLS control word [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.), immediately followed by a PPP data link layer (DLL) protocol number [RFC1661] (Simpson, W., “The Point-to-Point Protocol (PPP),” July 1994.). The 16 bit format of the PPP DLL protocol number MUST be used.

The MPLS pseudowire control word is shown in Figure 2. 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               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       PPP PID                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Packet Pseudowire Control Word

Note that the PPP link control protocol is not used.

4.  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 loacl LSR. This improves scaling in PE with large numbers of c-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.

5.  Congestion Considerations

This pseudowire is being used to carry MPLS and its associated support protocols over an MPLS network. There are no congestion considerations beyond those that ordinarily apply to an MPLS network.

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

7.  IANA Considerations

IANA are requested to allocate a new pseudowire type for packet pseudowire in the MPLS Pseudowire Types Registry. The next available value is requested.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses