Network Working Group                                     S. Bryant, Ed.
Internet-Draft                                                S. Boutros
Intended status: Standards Track                              L. Martini
Expires: January 9, 2010                                    S. Sivabalan
                                                              G. Swallow
                                                                D . Ward
                                                           Cisco Systems
                                                                A. Malis
                                                  Verizon Communications
                                                            July 8, 2009


            Packet Pseudowire Encapsulation over an MPLS PSN
                   draft-bryant-pwe3-packet-pw-01.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 January 9, 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.



Bryant, et al.           Expires January 9, 2010                [Page 1]


Internet-Draft                  Packet PW                      July 2009


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 [RFC2119].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Network Reference Model  . . . . . . . . . . . . . . . . . . .  3
   3.  Forwarding Model . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Encapsulation  . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Packet Pseudowire Control Word . . . . . . . . . . . . . . . .  6
   6.  Status Indication  . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Setting the load balance label . . . . . . . . . . . . . . . .  8
   8.  Client Network Layer Model . . . . . . . . . . . . . . . . . .  8
   9.  Congestion Considerations  . . . . . . . . . . . . . . . . . .  8
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     12.1.  Normative References  . . . . . . . . . . . . . . . . . .  9
     12.2.  Informative References  . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

















Bryant, et al.           Expires January 9, 2010                [Page 2]


Internet-Draft                  Packet PW                      July 2009


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].  The client may also be
   either a MPLS network of a network conforming to the MPLS-TP.
   Considerations as to whether an unrestricted MPLS 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].  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 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



Bryant, et al.           Expires January 9, 2010                [Page 3]


Internet-Draft                  Packet PW                      July 2009


   [RFC3985].


                  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

                                 Figure 1

   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.



Bryant, et al.           Expires January 9, 2010                [Page 4]


Internet-Draft                  Packet PW                      July 2009


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


   Packet PW Forwarding Model

                                 Figure 2

   A PW PE comprises two components, the PW processor and an LSR.  On
   receipt of a packet from the attachment circuit (AC) the PW
   undertakes any header processing, pushes the CW and pushes the PW
   label.  It then passes the packet to an LSR which pushes the label
   needed to reach the egress PE.  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 by the LSR.  The PW instance
   performs any required reconstruction using the CW and passes the
   packet directly to the attachment circuit.

   In the packet PW case an LSR belonging to the client layer is
   embedded within the equipment.  This determines the next hop in the
   client layer, pushes the label needed by the client next hop, and
   passes the packet to the correct PW instance indicating the packet
   protocol type.  The PW instance pushes CW (which included the
   protocol identifier), pushes the PW label and passes the packet to
   the server LSR for forwarding to the egress PW PE.  At the egress PE,
   the packet typically arrives with the PW label at the top of stack,
   the packet is thus directed to the correct PW instance by the server
   LSR.  This removes the CW and passes the packet to the client LSR
   indicating the protocol type.  The client LSR then forwards the
   packet based on the top label, which is a client layer label.

   Note that although the description above is written in terms of the
   behaviour of an MPLS LSR, the processing would model would be the
   same for IP.






Bryant, et al.           Expires January 9, 2010                [Page 5]


Internet-Draft                  Packet PW                      July 2009


4.  Encapsulation

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

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


               Figure 3: PWE3 Protocol Stack Reference Model

   The encapsulation of a packet PW is shown in Figure 4 below

    +-------------------------------+
    |      MPLS Tunnel label(s)     | n*4 octets (four octets per label)
    +-------------------------------+
    |          PW label             |  4 octets
    +-------------------------------+
    |         Control Word          |  6 octets
    +-------------------------------+
    |            Client             |
    |          Network Layer        |
    |            packet             |  n octets
    |                               |
    +-------------------------------+


      Figure 4: Encapsulation of a pseudowire with a pseudowire load
                              balancing label


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



Bryant, et al.           Expires January 9, 2010                [Page 6]


Internet-Draft                  Packet PW                      July 2009


   word [RFC4385], immediately followed by a PPP data link layer (DLL)
   protocol number [RFC1661].  The 16 bit format of the PPP DLL protocol
   number MUST be used.

   The MPLS pseudowire control word is shown in Figure 5.  Definitions
   of the fragmentation (FRG), length and sequence number fields are to
   be found in [RFC4385].


   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

                                 Figure 5

   Note that the PPP link control protocol is not used.

   Where the packet service being supported is a network layer service
   such as MPLS or IP, only a best effort packet ordering is normally
   required.  The sequence number would therefore normally be set to
   zero (no PW sequence number processing).


6.  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
   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] and in
   section 10 of [I-D.ietf-pwe3-segmented-pw] 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.






Bryant, et al.           Expires January 9, 2010                [Page 7]


Internet-Draft                  Packet PW                      July 2009


7.  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 a
   load balance label as described in [I-D.ietf-pwe3-fat-pw] may be
   included in the MPLS label stack.  Where the client service is MPLS
   it would be appropriate to copy the client layer, bottom of stack
   MPLS label into the load balance label.  Where the client layer is IP
   the load balance 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.


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


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


10.  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], [RFC4447]
   and [RFC3916].




Bryant, et al.           Expires January 9, 2010                [Page 8]


Internet-Draft                  Packet PW                      July 2009


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


12.  References

12.1.  Normative References

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, February 2006.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

12.2.  Informative References

   [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", draft-ietf-pwe3-fat-pw-00 (work in
              progress), July 2009.

   [I-D.ietf-pwe3-segmented-pw]
              Martini, L., Nadeau, T., Metz, C., Duckett, M., Bocci, M.,
              Balus, F., and M. Aissaoui, "Segmented Pseudowire",
              draft-ietf-pwe3-segmented-pw-12 (work in progress),
              June 2009.

   [RFC3916]  Xiao, X., McPherson, D., and P. Pate, "Requirements for
              Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
              September 2004.

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC5317]  Bryant, S. and L. Andersson, "Joint Working Team (JWT)
              Report on MPLS Architectural Considerations for a



Bryant, et al.           Expires January 9, 2010                [Page 9]


Internet-Draft                  Packet PW                      July 2009


              Transport Profile", RFC 5317, February 2009.


Authors' Addresses

   Stewart Bryant (editor)
   Cisco Systems
   250, Longwater, Green Park,
   Reading, Berks  RG2 6GB
   UK

   Phone: UK
   Fax:
   Email: stbryant@cisco.com
   URI:


   Sami Boutros
   Cisco Systems
   3750 Cisco Way
   San Jose, CA  95134
   USA

   Phone:
   Fax:
   Email: sboutros@cisco.com
   URI:


   Luca Martini
   Cisco Systems
   9155 East Nichols Avenue, Suite 400
   Englewood, CO  80112
   USA

   Phone:
   Fax:
   Email: lmartini@cisco.com
   URI:












Bryant, et al.           Expires January 9, 2010               [Page 10]


Internet-Draft                  Packet PW                      July 2009


   Siva Sivabalan
   Cisco Systems
   2000 Innovation Drive
   Kanata, Ontario  K2K 3EB
   Canada

   Phone:
   Fax:
   Email: msiva@cisco.com
   URI:


   George Swallow
   Cisco Systems
   1414 Massachusetts Ave
   Boxborough, MA  01719
   USA

   Phone:
   Fax:
   Email: swallow@cisco.com
   URI:


   David Ward
   Cisco Systems
   3750 Cisco Way
   San Jose, CA  95134
   USA

   Phone:
   Fax:
   Email: wardd@cisco.com
   URI:


   Andy Malis
   Verizon Communications
   117 West St.
   Waltham, MA  02451
   USA

   Phone:
   Fax:
   Email: andrew.g.malis@verizon.com
   URI:





Bryant, et al.           Expires January 9, 2010               [Page 11]