INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005 
 
                                                                        
Network Working Group                                         S. Bryant 
Internet Draft                                               G. Swallow 
Expiration Date: December 2005                            Cisco Systems 
                                                           D. McPherson 
                                                         Arbor Networks 
                                                                        
                                                              June 2005 
                                                                        
                                                                        
                PWE3 Control Word for use over an MPLS PSN 
                         draft-ietf-pwe3-cw-04.txt 
  
  
    
Status of this Memo  
   By submitting this Internet-Draft, each author represents that any    
   applicable patent or other IPR claims of which he or she is aware    
   have been or will be disclosed, and any of which he or she becomes    
   aware will be disclosed, in accordance with Section 6 of 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/1id-abstracts.html  
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 
Abstract  
 
   This document describes the preferred designs of the PWE3 MPLS 
   Control Word, and the Pseudo Wire Associated Channel Header. The 
   design of these fields is chosen so that an MPLS LSR performing MPLS 
   payload inspection will not confuse a PWE3 payload with an IP 
   payload. 
Conventions used in this document  
 
Bryant et al            Expires December 2005                [Page 1] 
 
INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005 
     
   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 RFC 2119 [RFC2119]. 
 
1.   Introduction 
   The standard MPLS encapsulations have no explicit protocol 
   identifier. In order for a pseudo wire (PW) [RFC3985] to operate 
   correctly over an MPLS packet switched network (PSN) that performs 
   MPLS payload inspection, a PW packet must not appear to the LSR as 
   if it were an IP packet [BCP]. An example of an LSR that performs 
   MPLS payload inspection is one that is performing equal-cost 
   multiple-path load-balancing (ECMP) [RFC2992]. If ECMP were 
   performed on PWE3 packets, the packets in the PW may not all follow 
   the same path through the PSN. This may result in misordered packet 
   delivery to the egress PE. The inability to ensure that all packets 
   belonging to a PW follow the same path may also prevent the PW OAM 
   [VCCV] mechanism from correctly monitoring the PW.  
   This draft specifies how a PW header distinguishes a PW payload from 
   an IP payload carried over an MPLS PSN. 
2.   PWE3 Packet Identification 
   All IP packets [RFC791][RFC1883] start with a version number that is 
   checked by LSRs performing MPLS payload inspection. To prevent the 
   incorrect processing of packets carried within a PW, PW packets 
   carried over an MPLS PSN MUST NOT start with the value 4 (IPv4) or 
   the value 6 (IPv6) in the first nibble [BCP], as those are assumed 
   to carry normal IP payloads. 
   This document defines a PW header and two general formats of that 
   header. These two formats are the PW MPLS Control Word (PWMCW) used 
   for data passing across the PW, and a PW Associated Channel Header 
   (PW-ACH) that can be used for functions such as OAM. 
   If the first nibble of a PWE3 packet carried over an MPLS PSN has a 
   value of 0, it starts with a PWMCW. If the first nibble of a packet 
   carried over an MPLS PSN has a value of 1, it starts with a PW-ACH. 
   The use of any other first nibble value for a PWE3 packet carried 
   over an MPLS PSN is deprecated. 
   A PW carried over an MPLS PSN that uses the contents of the MPLS 
   payload to select the ECMP path SHOULD employ the PW MPLS Control 
   Word described in Section 3 for data, or the PW Associated Channel 
   Header described in Section 4 for channel associated traffic. The 
   PWE3 Control Word or the PW Associated Channel Header MUST 
   immediately follow the bottom of the MPLS label stack. 
 
Bryant et al            Expires December 2005                [Page 2] 
 
INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005 
3.   Generic PW MPLS Control Word 
   The Generic PW MPLS Control Word is shown in Figure 1.  
 
    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|          Specified by PW Encapsulation                | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
         Figure 1: Generic PW MPLS Control Word 
 
 
   The PW set-up protocol or configuration mechanism determines whether 
   a PW uses a PW MPLS Control Word (PWMCW). Bits 0..3 differ from the 
   first four bits of an IP packet [BCP] and hence provide the 
   necessary MPLS payload discrimination. 
   When a PWMCW is used, it MUST adhere to the Generic MPLS Control 
   Word format as illustrated in Figure 1 above. It SHOULD also follow 
   the following format:  
 
    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               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        Figure 2: PW Preferred MPLS Control Word 
   The meaning of the fields of the PW Preferred MPLS Control Word 
   (Figure 2) is as follows: 
   Flags (bits 4 to 7): 
          These bits are available for per-payload signaling. 
   FRG (bits 8 and 9): 
          These bits are used when fragmenting a PW payload. Their use 
          is described in [FRAG] which is currently a work in progress. 
          When the PW is of a type that will never need payload 
          fragmentation, these bits may be used as general purpose 
          flags. 
   Length (bits 10 to 15): 
          When the PSN path between the PEs includes an Ethernet, the 
          PW packet arriving at the CE-bound PE from the PSN may 
 
Bryant et al            Expires December 2005                [Page 3] 
 
INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005 
          include padding appended by the Ethernet data link layer. The 
          CE-bound PE uses the length field to determine the size of 
          the padding added by the PSN, and hence extract the PW 
          payload from the PW packet. 
           
          If the entire packet length is less than 64 bytes, the length 
          field MUST be set to the length of the PW payload plus the 
          length of the control word. Otherwise it MUST be set to zero. 
   Sequence number (Bit 16 to 31): 
          The sequence number implements the sequencing function 
          [RFC3985]. The definition of this field is PW specific. 
4.   PW Associated Channel 
   For some features of PWs, such as OAM, an associated channel is 
   required. An associated channel is a channel that is multiplexed 
   over the PW so that it follows exactly the same path through the PSN 
   as the PW. Note that the use of the term "channel" is not a "PW 
   channel type" as used in subsection 5.1.2 of [RFC3985] 
   When MPLS is used as the PSN, the PW Associated Channel is 
   identified by the following header:  
   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 1| FmtID |   Reserved    |         Channel Type          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
       Figure 3: PW Associated Channel Header  
   The meanings of the fields in the PW Associated Channel Header 
   (Figure 3) are: 
   FmtID:  
          This is the Format Identifier for the remaining 3 octets of 
          the header. A Format Identifier value of 0 indicates that the 
          3 octets are as shown in Figure 3.  
   Reserved: 
          MUST be sent as 0, and ignored on reception. 
   Channel Type: 
          The PW Associated Channel Type is defined in the IANA PW 
          Associated Channel Type registry [IANA]. 
 
Bryant et al            Expires December 2005                [Page 4] 
 
INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005 
   Bits 0..3 MUST be 0001. This allows the packet the packet to be 
   distinguished from an IP packet [BCP] and from a PWE3 data packet.   
   Note that L2TPv3 [RFC3931] has its own mechanisms for providing this 
   associated channel, and is therefore out of the scope of this 
   document. 
5.   IANA considerations 
   IANA needs to set up a registry of "Pseudowire Associated Channel 
   Types". These are 16-bit values. Registry entries are assigned by 
   using the "IETF Consensus" policy defined in [RFC2434]. 
   IANA also needs to set up a registry of "Pseudowire Format 
   Identifiers". These are 4-bit values. Registry entries are assigned 
   by using the "IETF Consensus" policy defined in [RFC2434]. 
6.   Security Considerations 
   An application using PW Associated Channel to provide an OAM [VCCV] 
   or other message channel MUST be aware that this can potentially be 
   misused. Any application using the Associated Channel must therefore 
   fully consider the resultant security issues, and provide mechanisms 
   to prevent an attacker from using this as a mechanism to disrupt the 
   operation of the PW or the PE, and to stop this channel from being 
   used as a conduit to deliver packets elsewhere. 
   If a PW has been configured to operate without a CW, the PW 
   Associated Channel Type mechanism described in the document MUST NOT 
   be used. This is to prevent user payloads being fabricated in such a 
   way that they mimic the PW Associated Channel Header, and thereby 
   provide a method of attacking the application that is using the 
   Associated Channel. 
    
7.   Acknowledgements 
   The authors wish to thank David Allan, Luca Martini, Thomas Nadeau 
   Yaakov Stein, and Mark Townsley for their input to this work. 
    
8.   Intellectual Property Statement 
   The IETF takes no position regarding the validity or scope of any   
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
 
Bryant et al            Expires December 2005                [Page 5] 
 
INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005 
   it has made any independent effort to identify any such rights.  
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79. 
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an   
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at       
   ietf-ipr@ietf.org. 
 
9.    Full copyright statement 
   Copyright (C) The Internet Society (2005). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
10.    Normative References 
   Internet-drafts are works in progress available from   
   http://www.ietf.org/internet-drafts/ 
   [RFC791]   RFC-791: DARPA Internet Program, Protocol 
               Specification, ISI, September 1981. 
   [RFC1883]  RFC-1883: Internet Protocol, Version 6 (IPv6), S. 
               Deering, et al, December 1995 
    
 
Bryant et al            Expires December 2005                [Page 6] 
 
INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005 
    
11.    Informative References 
 
   Internet-drafts are works in progress available from   
    
   [BCP]     Swallow, G. et al, "Avoiding Equal Cost Multipath 
              Treatment in MPLS Networks", Internet Draft         
              , September 2004, 
              Work in Progress. 
   [FRAG]    Malis, A., Townsley, M., "PWE3 Fragmentation and 
              Reassembly", Internet Draft, , February 2005, Work in 
              Progress. 
   [IANA]    Martini, L., Townsley M., "IANA Allocations for 
              pseudo Wire Edge to Edge Emulation (PWE3) ", 
              Internet Draft, , April 2005, Work in Progress. 
               
   [RFC2434] RFC-2434: Guidelines for Writing an IANA 
              Considerations Section in RFCs, Narten, T., 
              Alvestrand, H., October 1998 
               
   [RFC2992] RFC-2992:  Analysis of an Equal-Cost Multi-Path 
              Algorithm, C. Hopps, November 2000 
               
   [RFC3985] RFC-3985: PWE3 Architecture, Bryant, S. ed., Pate, 
              P. ed., March 2005 
               
               
   [VCCV]    Nadeau, T., Aggarwal, T., "Pseudo Wire (PW) Virtual 
              Circuit Connection Verification (VCCV)", Internet 
              Draft, , Feb. 2005, 
              Work in Progress. 
 
 
12.    Authors' Addresses 
    
   Stewart Bryant 
   Cisco Systems, 
   250, Longwater, 
   Green Park, 
 
Bryant et al            Expires December 2005                [Page 7] 
 
INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Jun 2005 
   Reading, RG2 6GB, 
   United Kingdom.             Email: stbryant@cisco.com 
    
   Danny McPherson 
   Arbor Networks, Inc.              Email: danny@arbor.net 
    
   George Swallow 
   Cisco Systems, Inc. 
   1414 Massachusetts Ave 
   Boxborough, MA 01719        Email:  swallow@cisco.com 
    
 
Bryant et al            Expires December 2005                [Page 8]