Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks
draft-ietf-pwe3-tdm-control-protocol-extensi-07

Network Working Group                   A. Vainshtein (ECI Telecom)
     Internet Draft                 Y(J) Stein (RAD Data Communications)
                                                                        
     Intended Status:                                  Proposed Standard
                                                                        
     Creation Date:                                       March 20, 2008
                                                                        
     Expiration Date:                                     September 2008 
  
         Control Protocol Extensions for Setup of TDM Pseudowires  
                             in MPLS Networks 
  
           draft-ietf-pwe3-tdm-control-protocol-extensi-07.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 defines extension to the PWE3 control protocol [RFC4447] 
 and PWE3 IANA allocations [RFC4446] required for setup of TDM 
 pseudowires in MPLS networks. 
  
Vainshtein and Stein    Standards Track                  [Page 1]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 TABLE OF CONTENTS 
  
 1. Introduction......................................................2 
 2. PW FEC for Setup of TDM PWs.......................................3 
 3. Interface Parameters for TDM PWs..................................4 
   3.1. Overview......................................................4 
   3.2. CEP/TDM Payload Bytes.........................................4 
   3.3. CEP/TDM Bit-Rate (0x07).......................................5 
   3.4. Number of TDMoIP AAL1 cells per packet........................6 
   3.5. TDMoIP AAL1 mode..............................................6 
   3.6. TDMoIP AAL2 Options...........................................6 
   3.7. Fragmentation Indicator.......................................7 
   3.8. TDM Options...................................................7 
 4. Extending CESoPSN Basic NxDS0 Services with CE Application 
 Signaling............................................................9 
 5. LDP Status Codes.................................................10 
 6. Using the PW Status TLV..........................................10 
 7. IANA Considerations..............................................11 
 8. Security Considerations..........................................11 
 9. Acknowledgements.................................................11 
 10. Disclaimer of Validity..........................................12 
 11. Normative References............................................12 
 12. Informational References........................................12 
 13. Full Copyright Statement........................................13 
 14. Acknowledgement.................................................13 
 15. Authors' Addresses..............................................13 
  
  
 1. Introduction  
   
 This document defines extension to the PWE3 control protocol [RFC4447] 
 and PWE3 IANA allocations [RFC4446] required for setup of TDM 
 pseudowires in MPLS networks. 
   
 Structure-agnostic TDM pseudowires have been specified in [RFC4553]  
 and structure-aware ones in [RFC5086] and [RFC5087].  
   
 [RFC4447] defines extensions to LDP [RFC5036] that are required to  
 exchange PW labels for PWs emulating various Layer 2 services  
 (Ethernet, FR, ATM, HDLC etc.). Setup of TDM PWs requires both  
 interpretation of the existing information elements of these extensions  
 and exchange of additional information.   
   
 Setup of TDM PWs using L2TPv3 will be defined in a separate document.  
   
 Status of attachment circuits of TDM PWs can be exchanged between the  
 terminating PEs using the PW Status mechanism defined in [RFC4447] 
 without any changes. However, usage of this mechanism is NOT 
 RECOMMENDED for TDM PWs, since indication of status of the TDM 
 attachment circuits is carried in-band in the data plane.  
  
  
 Vainshtein and Stein       Expires September 2008            [Page 2]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 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. 
  
 2. PW FEC for Setup of TDM PWs  
   
 [RFC4447] uses LDP Label Mapping message [RFC5036] for advertising  
 the FEC-to-PW Label binding, and defines two types of PW FEC that can  
 be used for this purpose: 
  
  
 1. PWId FEC (FEC 128). This FEC contains:  
     a) PW type  
     b) Control bit (indicates presence of the control word)  
     c) Group ID   
     d) PW ID  
     e) Interface parameters  
 2. Generalized PW FEC (FEC 129). This FEC contains only:  
     a) PW type  
     b) Control bit  
     c) AGI, SAII and TAII that replace the PW ID  
       
 The Group ID and the Interface parameters are contained in separate  
 TLVs, called the PW Grouping TLV and the Interface Parameters TLV.   
   
 Either of these types of PW FEC MAY be used for setup of TDM PWs with 
 appropriate selection of PW types and interface parameters.   
   
   
 The PW Types for TDM PWs are allocated in [RFC4446] as follows:  
   
 o  0x0011  Structure-agnostic E1 over Packet [RFC4553]   
 o  0x0012  Structure-agnostic T1 (DS1) over Packet [RFC4553]  
 o  0x0013  Structure-agnostic E3 over Packet [RFC4553]  
 o  0x0014  Structure-agnostic T3 (DS3) over Packet [RFC4553]  
 o  0x0015  CESoPSN basic mode [RFC5086]  
 o  0x0016  TDMoIP AAL1 mode [RFC5087]  
 o  0x0017  CESoPSN TDM with CAS [RFC5086]  
 o  0x0018  TDMoIP AAL2 mode [RFC5087]  
   
 The two endpoints MUST agree on the PW type, as both directions of the  
 PW are required to be of the same type.  
   
 The Control bit MUST always be set for TDM PWs since all TDM PW  
 encapsulations always use a control word. 
  
 PW Type 0x0012 MUST also be used for setup of structure-agnostic TDM 
 PWs between a pair of J1 attachment circuits (see [RFC4805]). 
  
  
 Vainshtein and Stein       Expires September 2008            [Page 3]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 3. Interface Parameters for TDM PWs 
   3.1.     Overview 
  
 The interface parameters that are relevant for setup of the TDM PWs are 
 listed below. 
  
 ------------------------------------------------------------- 
 |   Interface Parameter |  Type      | Length | Description | 
 |-----------------------|------------|--------|-------------| 
 | CEP/TDM Payload Bytes | 0x04       | 4      |Section 3.2  | 
 |-----------------------|------------|--------|-------------| 
 | CEP/TDM Bit-Rate      | 0x07       | 6      |Section 3.3  | 
 |-----------------------|------------|--------|-------------| 
 | Number of TDMoIP AAL1 |TBA by IANA.| 4      |Section 3.4  | 
 | Cells per Packet      |Suggested:  |        |             | 
 |                       | 0x0E       |        |             | 
 |-----------------------|-------=----|--------|-------------| 
 | TDMoIP AAL1 mode      |TBA by IANA.| 4      |Section 3.5  | 
 |                       |Suggested:  |        |             | 
 |                       | 0x10       |        |             | 
 |-----------------------|------------|--------|-------------| 
 | TDMoIP AAL2 Options   |TBA by IANA | 8 or   |Section 3.6  | 
 |                       |Suggested:  | larger |             | 
 |                       | 0x11       |see note|             | 
 |-----------------------|------------|--------|-------------| 
 | Fragmentation         | 0x09       |  4     |Section 3.7  | 
 | Indicator             |            |        |             | 
 |-----------------------|------------|--------|-------------| 
 | TDM Options           | 0x0B       |  4, 8, |Section 3.8  | 
 |                       |            | or 12  |             | 
 ------------------------------------------------------------- 
  
 If not explicitly indicated otherwise in the appropriate description, 
 the value of the interface parameter is interpreted as an unsigned 
 integer of the appropriate size (16 or 32 bits). 
  
 Note: The length of basic TDMoIP AAL2 Options interface parameter is 8 
 bytes, and when the optional CID mapping bases field is used there is 
 one additional byte for each trunk transported. Thus if 1 trunk is 
 being supported, this message occupies 9 bytes. Since there can be no 
 more than 248 CIDs in a given PW, this can never exceed 256 (this when 
 when each channel comes from a different trunk). 248 channels 
 translates to less than 9 E1s, and so for this case the length is no 
 more than 17 bytes. A single PE is not required to support more than 10 
 AAL2 PWs (i.e., up to 2480 individual channels, which is more than 
 carried by a fully populated STM1). Thus the memory required to store 
 all the AAL2 mapping information is typically between 80 and 170 bytes 
 per PE.  
  
  
   3.2.     CEP/TDM Payload Bytes  
  
 This parameter is used for setup of all SAToP and CESoPSN PWs (i.e. PW  
  
 Vainshtein and Stein       Expires September 2008            [Page 4]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015 and 0x0017) and employs 
 the following semantics:  
   
 1. The two endpoints of a TDM PW MUST agree on the same value of 
     this parameter for the PW to be set up successfully.  
 2. Presence of this parameter in the PWId FEC or in the Interface 
     Parameters Field TLV is OPTIONAL. If this parameter is omitted, 
     default payload size defined for the corresponding service (see 
     [RFC4553], [RFC5086]) MUST be assumed  
 3. For structure-agnostic emulation, any value consistent with the 
     MTU of the underlying PSN MAY be specified 
  
 4. For CESoPSN PWs:  
     a) The specified value P MUST be an integer multiple of N, 
        where N is the number of timeslots in the attachment 
        circuit  
     b) For trunk-specific NxDS0 with CAS:  
        i)   (P/N) MUST be an integer factor of the number of 
           frames per corresponding trunk multiframe (i.e. 16 
           for an E1 trunk and 24 for a T1 or J1 trunk)  
        ii)  The size of the signaling sub-structure is not 
           accounted for in the specified value P. 
 5. This parameter MUST NOT be used for setup of TDMoIP PWs (i.e., 
     PWs with PW types 0x0016 and 0x0018). 
  
   3.3.     CEP/TDM Bit-Rate (0x07) 
  
 This interface parameter represents the bit-rate of the TDM service in  
 multiples of the "basic" 64 Kbit/s rate. Its usage for all types of TDM  
 PWs assumes the following semantics:  
   
 1. This interface parameter MAY be omitted if the attachment circuit  
     bit-rate can be unambiguously derived from the PW Type (i.e. for  
     structure-agnostic emulation of E1, E3 and T3 circuits). If this  
     value is omitted for the structure-agnostic emulation of T1 PW  
     Type, the basic emulation mode MUST be assumed.  
 2. If present, only the following values MUST be specified for  
     structure-agnostic emulation (see [RFC4553]:  
     a) Structure-agnostic E1 emulation  - 32   
     b) Structure-agnostic T1 emulation:  
        i)   MUST be set to 24 in the basic emulation mode   
        ii)  MUST be set to 25 for the "Octet-aligned T1" emulation mode  
     c) Structure-agnostic E3 emulation  - 535  
     d) Structure-agnostic T3 emulation  - 699  
 3. For all kinds of structure-aware emulation, this parameter MUST be  
     set to N where N is the number of DS0 channels in the corresponding  
     attachment circuit.  
   
 Note: The value 24 does not represent the actual bit-rate of the T1 or 
 J1 circuit (1,544 Mbit/s) in units of 64 kbit/s. The values mentioned  
 above are used for convenience. 
  
  
 Vainshtein and Stein       Expires September 2008            [Page 5]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 Note: A 4-byte space is reserved for this parameter for compatibility 
 with [RFC4842].  
  
   3.4.     Number of TDMoIP AAL1 cells per packet  
  
 This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 0x0016) 
 and specifies the number of 48-byte AAL1 PDUs per MPLS packet. Any 
 values consistent with the MTU of the underlying PSN MAY be specified. 
 If this parameter is not specified it defaults to 1 PDU per packet for 
 low bit-rates (CEP/TDM Bit-Rate less than or equal to 32), and to 5 for 
 high bit-rates (CEP/TDM Bit-Rate of 535 or 699). 
  
   3.5.     TDMoIP AAL1 mode  
  
 This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 0x0016) 
 and specifies the AAL1 mode. If this parameter is not present, the AAL1 
 mode defaults to "structured". When specified, the values have the 
 following significance: 
    0 - unstructured AAL1 
    2 - structured AAL1 
    3 - structured AAL1 with CAS. 
 The two endpoints MUST agree on the TDMoIP AAL1 mode. 
  
   3.6.     TDMoIP AAL2 Options  
  
 This parameter MUST be present for TDMoIP AAL2 mode PWs (PW type 
 0x0018) and has 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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |    0x0F       |    Length     | V |      ENCODING             | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      Maximum Duration                         | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                      CID mapping bases                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  
 The fields in this parameter are defined as follows: 
  
 V defines the VAD capabilities. Its values have the following 
 significance: 
      0 means that activity is only indicated by signaling 
      1 means that voice activity detection is employed 
      3 means this channel is always active. In particular, this channel 
      may be used for timing recovery. 
  
 Encoding specifies native signal processing performed on the payload. 
 When no native signal processing is performed (i.e. G.711 encoding) 
 this field MUST be zero. Other specific values that can be used in this 
 field are beyond the scope of this specification, but the two 
 directions MUST match for the PW setup to succeed. 
  
  
 Vainshtein and Stein       Expires September 2008            [Page 6]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 Maximum Duration specifies the maximum time allowed for filling an AAL2 
 PDU, in units of 125 microseconds. For unencoded 64 kbps channels this 
 numerically equals the maximum number of bytes per PDU, and MUST be 
 less than 64. For other encoding parameters, larger values may be 
 attained. 
  
 CID mapping bases is an OPTIONAL parameter, its existence and length 
 determined by the length field. If the mapping of AAL2 CID values to 
 physical interface and time slot is statically configured, or if AAL2 
 switching [Q.2630.1] is employed, this parameter MUST NOT appear. When 
 it is present, and the channels belong to N physical interfaces (i.e. N 
 E1s or T1s), it MUST be N bytes in length. Each byte represents a 
 number to be subtracted from the CID to get the timeslot number for 
 each physical interface. For example, if the CID mapping bases 
 parameter consists of the bytes 20 and 60, this signifies that timeslot 
 1 of trunk 1 corresponds to CID 21 and timeslot 1 of trunk 2 is called 
 61. 
  
  
   3.7.     Fragmentation Indicator  
  
 This interface parameter is specified in [RFC4446] and its usage is 
 explained in [RFC4623]. It MUST be omitted in the FEC of all TDM PWs 
 excluding trunk-specific NxDS0 services with CAS using the CESoPSN 
 encapsulation. In case of these services, it MUST be present in the PW 
 FEC if the payload size specified value P differs from Nx(number of 
 frames per trunk multiframe). 
  
  
   3.8.     TDM Options  
  
 This is a new interface parameter. Its Interface Parameter ID (0x08) 
 has been assigned by IANA, and its format is shown in Fig. 1 below: 
  
     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |  Parameter ID |    Length     |R|D|F|X|SP |CAS|   RSVD-1      | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |0|     PT      |   RSVD-2      |               FREQ            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                         SSRC                                  | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  
          Figure 1. Format of the TDM Options Interface Parameter 
  
  
 The fields shown in this diagram are used as follows: 
  
  
 Vainshtein and Stein       Expires September 2008            [Page 7]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 Parameter ID       Identifies the TDM PW Options interface parameter, 
                     value TBA by IANA 
 Length             4, 8 or 12 (see below) 
 R                  The RTP Header Usage bit: if set, indicates that 
                     the PW endpoint distributing this FEC expects to 
                     receive RTP header in the encapsulation. RTP header 
                     will be used only if both endpoints expect to 
                     receive it. If this bit is cleared, Length MUST be 
                     set to 4, otherwise it MUST be either 8 or 12 (see 
                     below). If the peer PW end point cannot meet this 
                     requirement, the Label Mapping message containing 
                     the FEC in question MUST be rejected with the 
                     appropriate status code (see Section 4 below). 
 D                  The Differential timestamping Mode bit: if set, 
                     indicates that the PW endpoint distributing this 
                     FEC expects the peer to use Differential 
                     timestamping mode in the packets sent to it. If the 
                     peer PW end point cannot meet this requirement, the 
                     Label Mapping message containing the FEC in 
                     question MUST be rejected with the appropriate 
                     status code (see Section 4 below). 
 F, X               Reserved for future extensions. MUST be cleared 
                     when distributed and MUST be ignored upon reception 
 SP                 Encodes support for the CESoPSN signaling packets 
                     (see [RFC5086]):  
                     o  '00' for PWs that do not use signaling 
                        packets 
                     o  '01' for CESoPSN PWs carrying TDM data 
                        packets and expecting CE application 
                        signaling packets in a separate PW 
                     o  '10' for a PW carrying CE application 
                        signaling packets with the data packets in a 
                        separate PW 
                     o  '11' - for CESoPSN PWs carrying TDM data and 
                        CE application signaling on the same PW 
 CAS                MUST be cleared for all types of TDM PWs excluding 
                     trunk-specific NxDS0 services with CAS. For these 
                     services it encodes the trunk framing like 
                     following: 
                     o  '01' - an E1 trunk 
                     o  '10' - a T1/ESF trunk 
                     o  '11' - a T1 SF trunk 
 RSVD-1 and RSVD-2  Reserved bits, MUST be set to 0 by the PW endpoint 
                     distributing this FEC and MUST be ignored by the 
                     receiver 
 PT                 Indicates the value of Payload Type in the RTP 
                     header expected by the PW endpoint distributing 
                     this FEC. Value 0 means that PT value check will 
                     not be used for detecting malformed packets 
 FREQ               Frequency of timestamping clock in units of 8 kHz 
 SSRC               Indicates the value of SSRC ID in the RTP header 
                     expected by the PW endpoint distributing this FEC. 
                     Value 0 means that SSRC ID value check will not be 
  
 Vainshtein and Stein       Expires September 2008            [Page 8]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
                     used for detecting misconnections. Alternatively, 
                     Length can be set to 8 in this case. 
  
  
 Notes: 
  
 1. This interface parameter MAY be omitted in the following cases: 
     a) SAToP PWs that do not use RTP header [RFC4553] 
     b) Basic CESoPSN NxDS0 services without CE application 
        signaling [RFC5086] 
     c) TDMoIP AAL1 mode 0 or 2 PWs that do not use RTP 
     d) TDMoIP AAL2 PWs that do not relay CAS signaling and do 
        not use RTP. 
 2. This interface parameter MUST be present in the following cases: 
     a) All TDM PWs that use RTP header 
     b) CESoPSN PWs that carry basic NxDS0 services and use 
        CESoPSN signaling packets to carry CE application 
        signaling. This case is discussed in detail in Section 4 
        below 
     c) CESoPSN PWs that carry trunk-specific NxDS0 services with 
        CAS 
     d) TDMoIP AAL1 mode 1 PWs 
     e) TDMoIP AAL2 PWs that relay CAS signaling.  
 3. If RTP header and possibly the Differential timestamping mode 
     are used, the value of the Length field MUST be set to 8 or 12 
     in order to accommodate the Timestamping Clock Frequency and 
     SSRC fields 
 4. Usage or non-usage of the RTP header MUST match for the two 
     directions making up the TDM PW. However, it is possible to use 
     Differential timestamping mode in just one direction.  
  
  
 4. Extending CESoPSN Basic NxDS0 Services with CE Application Signaling 
  
 [RFC5086] defines that basic NxDS0 services can be extended to carry CE 
 application signaling (e.g., CAS) in special signaling packets carried 
 in a separate PW. 
  
 The following rules define setup of matching pairs of CESoPSN PWs using 
 the PW Id FEC and the extensions defined above: 
  
 1. The two PWs MUST: 
     a) Have the same PW Type 
     b) Use the same setup method (i.e. either both use the PWId 
        FEC, or both use the Generalized PW FEC) 
     c) Have the same values of all the Interface Parameters 
        listed in Section 3.1 above with the exception of the 
        code point in the SP field of the TDM Options parameter:  
        i)   For the PW carrying TDM data packets the SP bits 
           MUST be set to '01' 
        ii)  For the PW carrying the signaling packets, the SP 
           bits MUST set to '10'  
 2. If the PWId FEC has been used: 
  
 Vainshtein and Stein       Expires September 2008            [Page 9]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
     a) The value of PW ID for the CESoPSN PW carrying TDM data 
        packets MUST be even 
     b) The value of PW ID for the CESoPSN PW carrying CE 
        application signaling MUST be the next (odd) value after 
        the (even) PW ID of the CESoPSN PW carrying TDM data 
        packets 
  
 When using the Generalized PW FEC for setup of the two PWs, no specific 
 rules for matching the two FECs are defined. Implementation specific 
 mechanisms MAY be employed to verify the proper matching of the TDM 
 data PW with its associated CE signaling PW. 
  
 If one of the two associated PWs has been established and the other 
 failed to be established, or for any reason fails after having been 
 established, the established PW MUST be torn down. 
  
 5. LDP Status Codes 
  
 In addition to the status codes defined in sections 5.1 and 7.2 of 
 [RFC4447], the following status codes defined in [RFC4446] MUST be used 
 to indicate the reason of failure to establish a TDM PW: 
  
 1. Incompatible bit rate: 
     a) In the case of mismatch of T1 encapsulation modes (basic 
        vs. octet-aligned) 
     b) In case of mismatch in the number of timeslots for NxDS0 
        basic services or trunk-specific NxDS0 services with CAS 
 2. CEP/TDM misconfiguration: 
     a) In the case of mismatch in the desired usage of RTP 
        header 
     b) In the case of mismatch of the desired timestamping clock 
        frequency 
     c) In the case of mismatch of expected signaling packets 
        behavior for basic CESoPSN NxDS0 services extended to 
        carry CE application signaling in separate signaling 
        packets 
     d) In the case of trunk-specific NxDS0 services with CAS if 
        the framing types of the trunks are different 
     e) In the case of TDMoIP AAL1 PWs with different AAL1 modes 
        specified by the end points 
 3. The generic misconfiguration error MAY be used to indicate any 
     setup failure not covered above. 
  
 In cases 2a, 2b, 2c and 2e above, the user MAY reconfigure the end 
 points and attempt to setup the PW once again. 
  
 In the case 2d the failure is fatal. 
  
 Note that setting of the Control bit (see section 2 above) to zero MUST 
 result in an LDP status of "Illegal C-Bit". 
  
 6. Using the PW Status TLV 
  
  
 Vainshtein and Stein       Expires September 2008           [Page 10]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 The TDM PW control word carries status indications for both attachment 
 circuits (L and M fields) and the PSN (R field) indication (see 
 [RFC4553], [RFC5086] and [RFC5087]). Similar functionality is available 
 via use of the PW Status TLV (see [RFC4447], Section 5.4.2).   
 If the latter mechanism is employed, the signaling PE sends its peer a 
 PW Status TLV for this PW, setting the appropriate bits (see [RFC4446], 
 Section 3.5): 
  
 o  Pseudo Wire Not Forwarding 
 o  Local Attachment Circuit (ingress) Receive Fault 
 o  Local Attachment Circuit (egress) Transmit Fault 
 o  Local PSN-facing PW (ingress) Receive Fault 
 o  Local PSN-facing PW (egress) Transmit Fault. 
  
 As long as the TDM PW interworking function is operational, usage of 
 the Status TLV is NOT RECOMMENDED in order to avoid contention between  
 status indications reported by the data and control plane. However, if 
 the TDM PW interworking function (IWF) itself fails while the PWE3  
 control plane remains operational, a Status TLV with all of the above 
 bits set SHOULD be sent.  
    
 7. IANA Considerations 
  
 Most of the IANA assignments required by this draft are already listed 
 in [RFC4446]. Additional assignments are required for three Interface 
 Parameters Sub-TLV type values (see Section 3.1):  
    
 o  Number of TDMoIP AAL1 cells per packet (suggested value - 0x0E)  
 o  TDMoIP AAL1 mode (suggested value - 0x10)  
 o  TDMoIP AAL2 Options (suggested value - 0x11).  
    
 8. Security Considerations 
  
 This draft does not have any additional impact on security of PWs above 
 that of basic LDP-based setup of PWs specified in [RFC4447]. 
  
 9. Acknowledgements 
  
 Sharon Galtzur has reviewed one of the previous versions of this 
 document. 
 Y(J)S would like to thank Barak Schlosser for helpful discussions. 
  
 Vainshtein and Stein       Expires September 2008           [Page 11]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 Disclaimer of Validity 
  
 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. 
  
 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.  Normative References 
  
 [RFC5036] L. Andersson et al, LDP Specification, RFC 5036, IETF, 2007 
  
 [RFC4447] L. Martini et al, Pseudowire Setup and Maintenance using LDP, 
 RFC 4447, 2006 
  
 [RFC4446] L. Martini, IANA Allocations for Pseudo Wire Edge to Edge 
 Emulation (PWE3), RFC 4446, 2006 
  
 [RFC4623] A. Malis, M. Townsley, PWE3 Fragmentation and Reassembly, RFC 
 4623, 2006 
  
 [RFC4553] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over Packet 
 (SAToP), RFC 4553, 2006 
  
 11.  Informational References 
  
 [RFC5086] A. Vainshtein et al, Structure-aware TDM Circuit Emulation 
 Service over Packet Switched Network (CESoPSN), RFC 5086, 2007 
  
 [RFC5087] Y(J) Stein et al, TDM over IP, RFC 5087 2007. 
  
 [Q.2630.1] ITU-T Recommendation Q.2630.1, December 1999, AAL type 2 
 signaling protocol - Capability set 1 
  
  
 Vainshtein and Stein       Expires September 2008           [Page 12]

  
 Control Protocol Extensions for TDM Pseudo wires March 2008 
           
 [RFC4805] O. Nicklass, Definitions of Managed Objects for the DS1, J1, 
 E1, DS2, and E2 Interface Types, RFC 4805, 2007 
  
 [RFC4842] A. Malis et al, Synchronous Optical Network/Synchronous 
 Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP), RFC 
 4842, 2007 
  
 12.  Full Copyright Statement 
  
 Copyright (C) The IETF Trust (2008).  
  
 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, THE IETF TRUST 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. 
  
  
 13.  Acknowledgement  
  
 Funding for the RFC Editor function is currently provided by the 
 Internet Society.  
  
 14.  Authors' Addresses 
  
 Alexander ("Sasha") Vainshtein 
 ECI Telecom 
 30 ha-Sivim St.,  
 PO Box 500 Petah-Tiqva, 49517 Israel 
 email: Alexander.Vainshtein@ecitele.com 
  
 Yaakov (Jonathan) Stein 
 RAD Data Communications 
 24 Raoul Wallenberg St., Bldg C 
 Tel Aviv  69719 
 ISRAEL 
  
 Phone: +972 3 645-5389 
 Email: yaakov_s@rad.com 
  
  
  
 Vainshtein and Stein       Expires September 2008           [Page 13]