Internet DRAFT - draft-ietf-pwe3-cw

draft-ietf-pwe3-cw







INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

 
                                                                        
Network Working Group                                         S. Bryant 
Internet Draft                                               G. Swallow 
Expiration Date: April 2006                                  L. Martini 
                                                          Cisco Systems 
                                                           D. McPherson 
                                                         Arbor Networks 
                                                                        
                                                           October 2005 
                                                                        
                PWE3 Control Word for use over an MPLS PSN 

                         draft-ietf-pwe3-cw-06.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 design of a PWE3 Control Word 
   to be use over an MPLS packet switched network, and the Pseudo Wire 
   Associated Channel Header. The design of these fields is chosen so 
   that an MPLS Label Switching Router performing MPLS payload 
   inspection will not confuse a PWE3 payload with an IP payload. 

    




 
Bryant et al              Expires April 2006                  [Page 1] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

Conventions used in this document  
     
   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 a label 
   switching router (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 PW 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 is used to distinguish a PW 
   payload from an IP payload carried over an MPLS PSN. It then 
   describes the preferred design of a PW Control Word to be use over 
   an MPLS PSN, and the Pseudo Wire Associated Channel Header. 

2.   Avoiding ECMP 

   A PW that is carried over an MPLS PSN that uses the contents of the 
   MPLS payload to select the ECMP path may be subjected to packet 
   misordering [BCP]. In cases where the application using the PW is 
   sensitive to packet misordering, or where packet misordering will 
   disrupt the operation of the PW, it is necessary to prevent the PW 
   being subjected to ECMP. 

   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) which 
   is used for data passing across the PW, and a PW Associated Channel 
   Header (PWACH) that can be used for functions such as OAM. 

   If the first nibble of a PW packet carried over an MPLS PSN has a 
   value of 0, it starts with a PWMCW. If the first nibble of a packet 





 
Bryant et al              Expires April 2006                  [Page 2] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

   carried over an MPLS PSN has a value of 1, it starts with a PWACH. 
   The use of any other first nibble value for a PW packet carried over 
   an MPLS PSN is deprecated. 

   If a PW is sensitive to packet misordering and is being carried over 
   an MPLS PSN that uses the contents of the MPLS payload to select the 
   ECMP path, it MUST employ a mechanism which prevents packet 
   misordering. A suitable mechanism is the PWMCW described in Section 
   3 for data, and the PWACH described in Section 4 for channel 
   associated traffic.  

   The PWMCW or the PWACH MUST immediately follow the bottom of the 
   MPLS label stack. 

3.   Generic PW MPLS Control Word 

   The Generic PW MPLS Control Word (PWMCW) 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 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 format 
   illustrated in Figure 1 above. To provide consistency between the 
   designs of different types of PW, it SHOULD also use the following 
   preferred 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: Preferred PW MPLS Control Word 

   The meaning of the fields of the Preferred PW MPLS Control Word 
   (Figure 2) is as follows: 

   Flags (bits 4 to 7): 




 
Bryant et al              Expires April 2006                  [Page 3] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

          These bits MAY be used by for per-payload signaling. Their 
          semantics MUST be defined in the PW specification. 

   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 
          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 MPLS payload is less than 64 bytes, the length field 
          MUST be set to the length of the PW payload plus the length 
          of the PWMCW. Otherwise it MUST be set to zero. 

   Sequence number (Bit 16 to 31): 

          The sequence number implements the sequencing function 
          [RFC3985]. The use of this field is described in Section 4. 

4.   Sequencing 

   The sequence number mechanism is PW specific. The PW encapsulation 
   specification MAY define a sequence number mechanism to be used, or 
   it may indicate that the mechanism described here is to be used. A 
   pseudo-code description of this mechanism is given in non-normative 
   Appendix 1. 

   The sequence number mechanism described here uses a circular 
   unsigned 16 bit number space that excludes the value zero. 

4.1    Setting the Sequence Number 

   For a given PW, and a pair of routers PE1 and PE2, if PE1 supports  
   frame sequencing and frame sequencing is enabled for the PW, then 
   the following procedures MUST be used:  

     o The initial frame transmitted on the PW MUST be sent with 
       sequence number one. 







 
Bryant et al              Expires April 2006                  [Page 4] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

     o Subsequent frames MUST increment the sequence number by one for 
       each frame. 

     o The sequence number that follows 65535 (maximum unsigned 16 bit 
       number) is one.  

   If the transmitting router PE1 does not support sequence number 
   processing, or frame sequencing is disabled, then the sequence 
   number field in the control word MUST be set to zero for all frames 
   transmitted on the PW.  

4.2    Processing the sequence number 

   If a router PE2 supports receive sequence number processing, and 
   frame sequencing is enabled for this PW, then the following 
   procedure is used:  

   When a PW is initially set up, the "expected sequence number"  
   associated with it MUST be initialized to one.  

   When a frame is received on that PW, the sequence number SHOULD be 
   processed as follows:  

     o If the sequence number on the frame is zero, the sequence 
       integrity of the packets cannot be determined. In this case, the 
       received frame is considered to be in order. 

     o Otherwise if the frame sequence number equals the expected 
       sequence number, the frame is in order.  

     o Otherwise if the frame sequence number is greater than the 
       expected sequence number, and the frame sequence number minus 
       the expected sequence number is less than 32768, the frame is 
       within the allowed receive sequence number window. The 
       implementation MAY treat the packet as is in order.  

     o Otherwise if the frame sequence number is less than the expected 
       sequence number and the expected sequence number minus the frame 
       sequence number is greater than or equal to 32768, the frame is 
       within the allowed receive sequence number window. The 
       implementation MAY treat the packet as is in order. 

     o Otherwise the frame is out of order. 

   If the frame is in order, it can be delivered immediately.  

   If the frame sequence number was not zero, then the expected 
   sequence number is set to the frame sequence number plus one. The 
   expected sequence number that follows 65535 (maximum unsigned 16 bit 
   number) is one. 





 
Bryant et al              Expires April 2006                  [Page 5] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

   Frames which are received out of order MAY either be dropped or 
   reordered. The choice between dropping or re-ordering an out of 
   sequence frame is at the discretion of the receiver.  
    
   If a PE negotiated not to use receive sequence number processing, 
   and it received a non zero sequence number, then it SHOULD send a PW 
   status message indicating a receive fault, and disable the PW. 

5.   PW Associated Channel 

   For some PW features, 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 (PWAC) 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|Version|   Reserved    |         Channel Type          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

       Figure 3: PW Associated Channel Header  

   The meanings of the fields in the PW Associated Channel Header 
   (PWACH) (Figure 3) are: 

   Version:  

          This is the version number of the PWACH. This specification 
          defines version 0. 

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

   Bits 0..3 MUST be 0001. This allows the packet to be distinguished 
   from an IP packet [BCP] and from a PW data packet.   









 
Bryant et al              Expires April 2006                  [Page 6] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

6.   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]. The value 
   0X21 indicates that the Associated Channel carries an IPv4 packet. 

7.   Security Considerations 

   An application using a PW Associated Channel must be aware that the 
   channel 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. The selection of a suitable security mechanism 
   for an application using a PW Associated Channel is outside the 
   scope of this document. 

   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. 

8.   Acknowledgements 

   The authors wish to thank David Allan, Thomas Nadeau, Yaakov Stein, 
   and Mark Townsley for their input to this work. 

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







 
Bryant et al              Expires April 2006                  [Page 7] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

   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. 

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

11.    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 April 2006                  [Page 8] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

    

12.    Informative References 

 
   Internet-drafts are works in progress available from   
   <http://www.ietf.org/internet-drafts/> 

   [BCP]     Swallow, G. et al, "Avoiding Equal Cost Multipath 
              Treatment in MPLS Networks", Internet Draft         
              <draft-ietf-mpls-ecmp-bcp-01.txt>, July 2005, Work 
              in Progress. 

   [FRAG]    Malis, A., Townsley, M., "PWE3 Fragmentation and 
              Reassembly", Internet Draft, <draft-ietf-pwe3-
              fragmentation-09.txt>, September 2005, Work in 
              Progress. 

   [IANA]    Martini, L., Townsley M., "IANA Allocations for 
              pseudo Wire Edge to Edge Emulation (PWE3) ", 
              Internet Draft, <draft-ietf-pwe3-iana-allocation-
              12.txt>, September 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 
               
               
 

















 
Bryant et al              Expires April 2006                  [Page 9] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

 
13.    Authors' Addresses 

    
   Stewart Bryant 
   Cisco Systems, 
   250, Longwater, 
   Green Park, 
   Reading, RG2 6GB, 
   United Kingdom.             Email: stbryant@cisco.com 
    
   Luca Martini 
   Cisco Systems, Inc. 
   9155 East Nichols Avenue, Suite 400 
   Englewood, CO, 80112        Email: lmartini@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 
    
14.    Appendix 1 Sequence Number Processing 

   This appendix is non-normative. 

   This appendix provides a pseudo-code description of the sequence 
   number processing mechanism described in Section 4.2. 

   unsigned16 RECEIVED     /* frame sequence number 
   unsigned16 EXPECTED = 1 /* expected sequence number 
                           /* initialized to one 
   boolean sequencingDisabled 
   boolean dropOutOfOrder  /* policy on in-window out of sequence 
                           /* frames 
    
   updateExpected() 
   begin 
       EXPECTED := RECEIVED + 1; 
       /* Because EXPECTED is an unsigned16 it will wrap 
       /* from 65535 to 0 
       /* zero is skipped 
       if (EXPECTED = 0) 
           EXPECTED := 1;  
       return; 
   end; 
    
    





 
Bryant et al              Expires April 2006                 [Page 10] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

   On receipt of a PW packet from PSN: 
   begin 
       if (RECEIVED = 0) then begin 
           processFrame();  
           return; 
       end; 
    
       if (sequencingDisabled) then begin 
           /* A frame was received with non-zero sequence number, but 
           /* sequencing is disabled 
           indicateReceiveFault(); 
           disablePW(); 
           return; 
       end; 
        
       /* The received sequence is the expected sequence number 
       if ((RECEIVED = EXPECTED) then begin 
           /* packet is in order 
           processFrame();  
           updateExpected(); 
           return; 
       end; 
    
       /* Test for received sequence number is greater than 
       /* the expected sequence number and is within the  
       /* allowed receive sequence number window 
       if ((RECEIVED > EXPECTED) and 
           ((RECEIVED - EXPECTED) < 32768) then begin 
           /* frame is in the window, but there are late/missing 
           /* frames 
           if (dropOutOfOrder) then begin 
               /* policy is to receive immediately, dropping 
               /* out of sequence frames 
               processFrame();  
               updateExpected(); 
               return; 
           end else begin 
               /* policy is to wait for late packets 
               processMissingFrames();  
               return; 
           end; 
       end; 
    
       /* Test for the received sequence is less than the  
       /* expected sequence number and is within the allowed 
       /* receive sequence number window 
       if ((RECEIVED < EXPECTED) and 
           ((EXPECTED - RECEIVED) >= 32768) then begin 
           /* frame is in the window, but there are late/missing 
           /* frames 





 
Bryant et al              Expires April 2006                 [Page 11] 
 



INTERNET DRAFT   PWE3 Control Word for use over an MPLS PSN   Oct 2005 

           if (dropOutOfOrder) then begin 
               /* policy is to receive immediately, dropping 
               /* out of sequence frames 
               processFrame();  
               updateExpected(); 
               return; 
           end else begin 
               /* policy is to wait for late packets 
               processMissingFrames();  
               return; 
           end; 
       end; 
    
       /* Received packet was outside the allowed receive 
       /* sequence number window 
       processOutOfWindow(); 
   end; 
    





































 
Bryant et al              Expires April 2006                 [Page 12]