Network Working Group A. Vainshtein (Axerra Networks) Internet Draft Expiration Date: July 2004 January 2004 Control Protocol Extensions for Setup of TDM Pseudowires draft-vainshtein-pwe3-tdm-control-protocol-extensi-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026. 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. Abstract This document defines extension to the PWE3 control protocol [PWE3- CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of TDM pseudowires. TABLE OF CONTENTS 1. Introduction......................................................2 2. PW FEC for Setup of TDM PWs.......................................2 3. Interface Parameters for TDM PWs..................................3 3.1. CEP Payload Bytes.............................................3 3.2. CEP/TDM Bit-Rate..............................................3 3.3. Fragmentation Indicator.......................................4 3.4. TDM Options...................................................4 4. LDP Status Codes..................................................6 5. IANA Considerations...............................................6 6. Security considerations...........................................6 7. Acknowledgements..................................................7 8. REFERENCES........................................................7 8.1. MANDATORY REFERENCES..........................................7 8.2. INFORMATIONAL REFERENCES......................................7 Vainshtein et al. Standards Track Page 1 Control Protocol Extensions for Setup of TDM Pseudowires January 2004 1. Introduction This document defines extension to the PWE3 control protocol [PWE3- CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of TDM pseudowires. Structure-agnostic TDM pseudowires have been specified in [PWE3-SAToP] and structure-aware ones in [PWE3-CESoPSN] and [PWE3-TDMoIP]. [PWE3-CONTROL] defines extensions of LDP [RFC3036] 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 mechanism defined in [PWE3-CONTROL] and [SHAH-PWE3-CONTROL-EXT] without any changes. However, usage of these mechanisms with TDM PWs is NOT RECOMMENDED since indication of status of the TDM attachment circuits is carried in-band in the data plane. 2. PW FEC for Setup of TDM PWs [PWE3-CONTROL] uses Label Mapping message [RFC3036] 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. 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 ID FEC. In this FEC, PW ID and Group ID are replaced by PW AGI, SAII and TAII, but the control bit, the PW type and the interface parameters remain the same as in the PWid FEC. Both types of PW FEC can be used for setup of TDM PWs with appropriate selection of PW types and interface parameters. The Control bit MUST always be set for setup of TDM PWs since all TDM PW encapsulations use an appropriate control word. 3. PW Types for TDM PWs [PWE3-CONTROL] defines the PW Type as a 15-bit quantity, and [PWE3- IANA] allocates values from 0x01 to 0x9 for Layer 2 services, and value 0x10 for SONET emulation (CEP). Vainshtein Expires July 2004 [Page 2] Control Protocol Extensions for Setup of TDM Pseudowires January 2004 The following different PW types have to be allocated for TDM PWs: 1. Structure-agnostic emulation [PWE3-SAToP] of: a) E1 circuits - TBA by IANA b) T1 circuits - TBA by IANA c) E3 circuits - TBA by IANA d) T3 circuits - TBA by IANA 2. Structure-aware emulation [PWE3-CESoPSN], [PWE3-TDMoIP] of: a) Basic NxDS0 service emulation - TBA by IANA b) E1-originated NxDS0 service with CAS - TBA by IANA c) T1/ESF-originated NxDS0 service with CAS - TBA by IANA d) T1/SF-originated NxDS0 service with CAS - TBA by IANA. 3. Interface Parameters for TDM PWs 3.1. CEP Payload Bytes This parameter has been initially defined for usage with CEP [PWE3- SONET] PWs. It can be used for setup of all types of TDM PWs without any changes in its encoding (see [PWE3-IANA]) with the following semantics: 1. The two endpoints of a TDM PW MUST agree on the same value of this parameter 2. If this parameter is omitted, default payload size defined for the corresponding service (see [PWE3-SAToP], [PWE3-CESoPSN], [PWE3- TDMoIP] MUST be assumed 3. For structure-agnostic emulation, any value 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 of a T1 trunk) ii) The size of the signaling sub-structure is not accounted for in the specified value P. 5. For TDMoIP N MUST be an integer multiple of 48. Note: This interface parameter should be renamed to "CEP/TDM Payload Bytes". 3.2. CEP/TDM Bit-Rate Encoding of this interface parameter is defined in [PWE3-IANA]. 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 [PWE3-SAToP]: Vainshtein Expires July 2004 [Page 3] Control Protocol Extensions for Setup of TDM Pseudowires January 2004 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 circuit (1,544 Mbit/s) in units of 64 kbit/s. It is selected for the reasons of convenience only. 3.3. Fragmentation Indicator This interface parameter is specified in [PWE3-IANA] and its usage is explained in [PWE3-FRAG]. 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.4. TDM Options This is a new interface parameter. Its Interface Parameter ID has to be 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| 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 following: Vainshtein Expires July 2004 [Page 4] Control Protocol Extensions for Setup of TDM Pseudowires January 2004 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 Dynamic 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 The CESoPSN/TDMoIP "flavor" bit for structure-aware TDM PWs: if set, indicates that the PW endpoint distributing this FEC expects to receive the TDMoIP encapsulation, otherwise it expects the CESoPSN encapsulation. If the peer PW end point cannot operate in the expected flavor, the Label Mapping message containing the FEC in question MUST be rejected with the appropriate status code (see Section 4 below). 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 the timestamping clock in the 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 used for detecting misconnections. Alternatively, Length can be set to 8 in this case. Notes: 1. This interface parameter MAY be omitted for default mode of operation of structure-agnostic TDM PWs (i.e., where no RTP header is used and basic encapsulatio mode is used for T1 attachment circuits) but MUST be present for structure-aware emulation (in Vainshtein Expires July 2004 [Page 5] Control Protocol Extensions for Setup of TDM Pseudowires January 2004 order to distinguish between CESoPSN and TDMoIP flavors) and for octet-aligned T1 mode 2. If RTP header and Differential timestamping mode are used, the value of the Length field MUST be set to 8 or 12 in order to include at least the Timestamping Clock Frequency field in the value 3. A TDM PW encapsulation MUST either use or not use RTP in both directions. However, it is possible to use Differential timestamping mode in just one direction of the PW 4. Attempt to set up a structure-agnostic TDM PW between two end points where one intends to receive Octet-aligned T1 encapsulation mode while the other intends to use the basic mode MUST fail indicating incompatible bit-rates [PWE3-IANA]. 4. LDP Status Codes In addition to LDP status codes mentioned in [RFC3036] and [PWE3-IANA], the following status codes MUST be used to indicate specific reason of failure to establish a TDM PW: 1. "Incompatible RTP header mode" - TBA by IANA. If this status code is detected, both PW endpoints MUST switch to the default mode of operation, i.e. without RTP header 2. "Incompatible timestamping mode" - TBA by IANA. If this status code is detected, both PW endpoints MUST switch to the default mode of operation, i.e., absolute timestamping 3. "Incompatible flavors" - TBA by IANA. This status indicates failure to establish a structure-aware TDM PW due to different flavors (CESoPSN vs. TDMoIP) used by the PW endpoints. This failure is fatal 4. "Incompatible PT check mode" - TBA by IANA. If this status is detected, both PW end points must revert to the default mode of operation, i.e. no PT check 5. "Incompatible SSRC check mode" - TBA by IANA. If this status is detected, both PW end points must revert to the default mode of operation, i.e. no SSRC check 6. "Incompatible clock frequency" - TBA by IANA. If this status is detected, both PW end points must revert to the default mode of operation, 8 kHz timestamping clock frequency. 5. IANA Considerations This draft requires assignment of the following values by IANA: a) PW types listed in Section 2 above 2. Interface Parameter ID value for the TDM PW Options parameter described in Section 3.3 above 3. New LDP status codes described in Section 4 above. 6. Security considerations This draft does not have any impact on security of PWs. Vainshtein Expires July 2004 [Page 6] Control Protocol Extensions for Setup of TDM Pseudowires January 2004 7. Acknowledgements I thank Sharon Galtzur and Yaakov Stein for reviewing this text. 8. REFERENCES 8.1. MANDATORY REFERENCES [RFC2119] S. Bradner, Key Words in RFCs to Indicate Requirement Levels, RFC 2119, IETF, 1997 [RFC3036] L. Andersson et al, LDP Specification, RFC 3036, IETF, 2001 [PWE3-CONTROL] L. Martini et al, Pseudowire Setup and Maintenance using LDP, Work in progress, December 2003, draft-ietf-pwe3-control-protocol- 05.txt [PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3), Work in progress, October 2003, draft- ietf-pwe3-iana-allocation-02.txt [PWE3-FRAG] A. Malis, M. Townsley, PWE3 Fragmentation and Reassembly, Work in progress, December 2003, draft--ietf-pwe3-fragmentation-04.txt [PWE3-SAToP] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over Packet (SAToP), Work in Progress, December 2004, draft-ietf-pwe3-SAToP- 01.txt 8.2. INFORMATIONAL REFERENCES [SHAH-PWE3-CONTROL-EXT] H. Shah, H. Ould-Brahim, Dynamic Parameters Signaling for MPLS-based Pseudowires, Work in progress, June 2003, draft-shah-pwe3-control-protocol-extension-01.txt [PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN), Work in progress, January 2004, draft-ietf-pwe3-cesopsn-00.txt [PWE3-TDMoIP] Y. Stein et al, TDM over IP, Work in progress, draft- ietf-pwe3-tdmoip-00.txt, February 2004. Author's Address Alexander ("Sasha") Vainshtein Axerra Networks 24 Raoul Wallenberg St., Tel Aviv 69719, Israel email: sasha@axerra.com Full Copyright Statement Vainshtein Expires July 2004 [Page 7] Control Protocol Extensions for Setup of TDM Pseudowires January 2004 Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Vainshtein Expires July 2004 [Page 8]