summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5611.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5611.txt')
-rw-r--r--doc/rfc/rfc5611.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc5611.txt b/doc/rfc/rfc5611.txt
new file mode 100644
index 0000000..9eead43
--- /dev/null
+++ b/doc/rfc/rfc5611.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group A. Vainshtein
+Request for Comments: 5611 ECI Telecom
+Category: Standards Track S. Galtzur
+ Rebellion
+ August 2009
+
+
+ Layer Two Tunneling Protocol version 3 -
+ Setup of Time-Division Multiplexing (TDM) Pseudowires
+
+Abstract
+
+ This document defines extensions to the Layer Two Tunneling Protocol
+ version 3 (L2TPv3) for support of structure-agnostic and structure-
+ aware (Circuit Emulation Service over Packet Switched Network
+ (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires.
+ Support of structure-aware (Time-Division Multiplexing over IP
+ (TDMoIP) style) pseudowires over L2TPv3 is left for further study.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the
+ "Internet Official Protocol Standards" (STD 1) for the
+ standardization state and status of this protocol. Distribution of
+ this memo is unlimited.
+
+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.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+
+
+
+
+Vainshtein & Galtzur Standards Track [Page 1]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Conventions Used in This Document ..........................3
+ 2. L2TPv3 Extensions ...............................................3
+ 2.1. TDM PW Attribute-Value Pair (AVP) (ICRQ, OCRQ) .............4
+ 2.2. RTP Attribute-Value Pair (AVP) (ICRQ, OCRQ, ICRP, OCRP) ....6
+ 2.3. Changes in the Control Connection Management AVPs ..........7
+ 2.4. Changes in the Session Management AVPs .....................7
+ 3. Creation of the TDM Pseudowire Session ..........................7
+ 4. IANA Considerations .............................................9
+ 5. Congestion Control ..............................................9
+ 6. Security Considerations ........................................10
+ 7. Acknowledgements ...............................................10
+ 8. References .....................................................10
+ 8.1. Normative References ......................................10
+ 8.2. Informative References ....................................10
+
+1. Introduction
+
+ This document defines extensions to the Layer Two Tunneling Protocol
+ Version 3 (L2TPv3) for support of structure-agnostic [RFC4553] and
+ structure-aware (CESoPSN style, see [RFC5086]) Time-Division
+ Multiplexing (TDM) pseudowires. Structure-agnostic encapsulation of
+ TDM bit-streams over L2TPv3 is described in [RFC4553], Figure 2b;
+ Circuit Emulation Service over Packet Switched Networks (CESoPSN),
+ structure-aware encapsulation is described in [RFC5086], Figures 1c
+ (TDM data packets) and 4a (CE application signaling packets).
+ However, the order of the CESoPSN Control Word (CW) and RTP header
+ (if it is used) MUST match between the TDM data and CE signaling
+ packets.
+
+ Setup of structure-aware TDM pseudowires using the encapsulations
+ described in [RFC5087] has been left for further study.
+
+ Setup and maintenance of TDM pseudowires (PWs) in MPLS networks using
+ LDP is described in [RFC5287].
+
+
+
+
+
+
+
+
+
+
+Vainshtein & Galtzur Standards Track [Page 2]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+1.1. Conventions Used in This Document
+
+ In this document, we refer to the "control plane" as meaning the
+ packets that contain control information (via Attribute-Value Pairs
+ (AVPs)) and the mechanism that handles these packets. We also refer
+ to the "data plane" as meaning the packets that contain transported
+ user data.
+
+ 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].
+
+2. L2TPv3 Extensions
+
+ The L2TPv3 Control Connection is responsible for 3 main operations:
+
+ 1. Establishment and validation of a pseudowire (PW) session.
+
+ 2. Ending (tearing down) of a pseudowire session.
+
+ 3. Transferring of End Point status.
+
+ Tearing down of the session for a TDM pseudowire is performed
+ following the L2TPv3 tear-down operations as described in Section
+ 3.4.3 of [RFC3931].
+
+ [RFC5086] and [RFC4553] describe how to transfer the Attachment
+ Circuit (AC) status via the data plane. Therefore, the Set-Link-Info
+ (SLI) message described in [RFC3931] SHOULD NOT be used for conveying
+ this status for the PWs in question.
+
+ [RFC3931] specifies that the Circuit Status Attribute-Value Pair
+ (AVP) MUST be present in the ICRQ/ICRP (Incoming-Call-Request /
+ Incoming-Call-Reply) messages. It also specifies that the N bit in
+ this AVP should be set during the PW setup, even if the specific AC
+ does not provide any way to convey the "new AC" indication.
+ Accordingly, the Circuit Status AVP for the PWs in question, when
+ used in the ICRQ/ICRP messages, MUST always have both N and A bits
+ set.
+
+ The next sections describe the extensions to L2TPv3 for establishment
+ and validation of TDM pseudowire sessions.
+
+ There are two new AVPs for the Session Management messages. One AVP
+ describes the TDM pseudowire attributes. The second AVP describes
+ the RTP attributes for this TDM pseudowire.
+
+
+
+
+
+Vainshtein & Galtzur Standards Track [Page 3]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+2.1. TDM PW Attribute-Value Pair (AVP) (ICRQ, OCRQ)
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |M|H| rsvd | Length | Vendor Id (IETF) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute Type (99) | Reserved |SP |CAS|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Bit Rate | Payload Bytes |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this
+ AVP SHOULD be set to 0. The Length (before hiding) of this AVP is
+ 12.
+
+ The Bit Rate field contains the value that represents the bit rate of
+ the local AC in the units of 64 Kbit/s, encoded as an unsigned 16-bit
+ integer. Its usage for all types of TDM PWs employs the following
+ semantics:
+
+ 1) For structure-agnostic emulation, this parameter MUST be set to
+ one of the following values (see [RFC4553]):
+
+ a) Structure-agnostic E1 emulation - 32
+
+ b) Structure-agnostic T1 emulation:
+
+ i) MUST be set to 24 for the basic mode
+
+ ii) MUST be set to 25 for the "Octet-aligned T1" mode
+
+ c) Structure-agnostic E3 emulation - 535
+
+ d) Structure-agnostic T3 emulation - 699
+
+ 2) For CESoPSN PWs, this parameter MUST be set to the number of DS0
+ channels in the corresponding attachment circuit.
+
+ Note: For structure-agnostic T1 emulation, the values 24 and 25 do
+ not reflect the exact bit rate and are used for convenience only.
+
+ Note: The semantics of the Bit Rate field defined above are
+ consistent with those of the CEP/TDM Bit-Rate interface parameter as
+ defined in [RFC5287].
+
+
+
+
+
+
+Vainshtein & Galtzur Standards Track [Page 4]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+ The Payload Bytes field contains the value representing the number of
+ TDM payload bytes in the PW packet and is used with the following
+ semantics:
+
+ 1) For structure-agnostic emulation, any value of the Payload Bytes
+ can be specified.
+
+ 2) For CESoPSN PWs:
+
+ a) The specified value MUST be an integer multiple of the number
+ of DS0 channels in the corresponding attachment circuit.
+
+ b) In addition to that, for trunk-specific NxDS0 with Channel-
+ Associated Signaling (CAS), the number of the trunk frames per
+ multiframe fragment (value resulting from the Payload Bytes
+ divided by the number of DS0 channels) MUST be an integer
+ divisor of the number of frames per corresponding trunk
+ multiframe.
+
+ The Reserved bits MUST be set to 0 on transmission and MUST be
+ ignored on reception.
+
+ The SP bits define support for the CESoPSN-application signaling
+ packets (see [RFC5086]) and MUST be used as follows:
+
+ 1) Set to '01' for the CESoPSN PWs carrying TDM data packets and
+ expecting CE application signaling packets in a separate PW.
+
+ 2) Set to '10' for a PW carrying CE application signaling packets
+ with the data packets in a separate PW.
+
+ 3) Set to '11' for a CESoPSN PW carrying both TDM data and signaling
+ packets.
+
+ 4) Set to '00' for Structure-Agnostic Time-Division Multiplexing over
+ Packet (SAToP) PWs and for CESoPSN PWs not using separate
+ signaling packets.
+
+ The CAS bits define the trunk type for trunk-specific CESoPSN
+ services with CAS. These bits MUST be set to:
+
+ 1) For trunk-specific CESoPSN with CAS:
+
+ a) '01' in the case of an E1 trunk
+
+ b) '10' in the case of a T1/ESF trunk
+
+ c) '11' in the case of a T1/SF trunk
+
+
+
+Vainshtein & Galtzur Standards Track [Page 5]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+ 2) '00' for all the other TDM pseudowire types
+
+2.2. RTP Attribute-Value Pair (AVP) (ICRQ, OCRQ, ICRP, OCRP)
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |M|H| rsvd | Length | Vendor Id (IETF) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute Type (100) |D| PT |C| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved | Timestamp Clock Frequency |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SSRC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Presence of this AVP indicates that the RTP header is used in the TDM
+ pseudowire encapsulation. Use or non-use of the RTP header MUST
+ match for the two directions of a TDM PW. This AVP MAY be hidden
+ (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to
+ 0. The Length (before hiding) of this AVP is 16.
+
+ The D bit indicates the timestamping mode (absolute or differential)
+ in the RTP header. These modes are described in, e.g., Section 4.3.2
+ of [RFC4553]. If the D bit is set to 1, then the differential
+ timestamping mode is used; otherwise, the absolute timestamping mode
+ is used. Timestamping modes can be used independently for the two
+ directions of a TDM PW.
+
+ The C bit indicates the ordering of the RTP header and the Control
+ Word as following:
+
+ o If the C bit is set to 1, the RTP header appears after the Control
+ Word in the data channel of the TDM pseudowire. This mode is
+ described in [RFC4553] and [RFC5086] as SAToP/CESoPSN encapsulation
+ over IPv4/IPv6 PSN with L2TPv3 demultiplexing, respectively.
+
+ o If the C bit is set to 0, the RTP header appears before the Control
+ Word. This mode is described as the old mode of the SAToP/CESoPSN
+ encapsulation over L2TPv3 in Appendix A of [RFC4553] and Appendix C
+ of [RFC5086], respectively.
+
+ PT is the payload type expected in the RTP header. A value of 0
+ indicates that the receiver shall not check payload type to detect
+ malformed packets.
+
+ Timestamp Clock Frequency is the clock frequency used for
+ timestamping in units of 8 KHz.
+
+
+
+Vainshtein & Galtzur Standards Track [Page 6]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+ SSRC indicates the expected value of the synchronization source
+ (SSRC) ID in the RTP header. A 0 in this field means that the SSRC
+ ID will not be used for detecting misconnections. Since L2TP
+ provides an alternative security mechanism using cookies, if the
+ cookie length is larger than 0, the SSRC SHOULD be 0.
+
+2.3. Changes in the Control Connection Management AVPs
+
+ Control Connections that support TDM PWs MUST add the appropriate PW
+ Type value(s) to the list in the Pseudowire Capabilities List AVP.
+ The valid values are listed in the next section.
+
+2.4. Changes in the Session Management AVPs
+
+ PW Type AVP should be set to one of the following values:
+
+ 1. Structure-agnostic emulation [RFC4553] of:
+
+ a. E1 circuits - 0x0011
+
+ b. T1 (DS1) circuits - 0x0012
+
+ c. E3 circuits - 0x0013
+
+ d. T3 (DS3) circuits - 0x0014
+
+ 2. Structure-aware emulation [RFC5086] of:
+
+ a. CESoPSN basic mode - 0x0015
+
+ b. Trunk-specific CESoPSN service with CAS - 0x0017
+
+ TDM pseudowires use their own Control Word. Therefore, the L2-
+ Specific Sublayer AVP MUST either be omitted or set to 0.
+
+ TDM pseudowires use their own sequencing. Therefore, the Data
+ Sequencing AVP MUST either be omitted or set to 0.
+
+ Note: The Control Word (CW) used in the SAToP and CESoPSN
+ encapsulations over L2TPv3 effectively represents a dedicated L2-
+ Specific Sublayer.
+
+3. Creation of the TDM Pseudowire Session
+
+ When an L2TP Control Connection Endpoint (LCCE) wants to open a
+ Session for a TDM PW, it MUST include the TDM PW AVP (in any case)
+ and the RTP AVP (if and only if the RTP header is used) in the ICRQ
+ or OCRQ (Outgoing-Call-Request) message. The LCCE peer must validate
+
+
+
+Vainshtein & Galtzur Standards Track [Page 7]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+ the TDM PW AVP and make sure it can meet the requirements derived
+ from the RTP AVP (if it exists). If the peer agrees with the TDM
+ AVP, it will send an appropriate ICRP or OCRP (Outgoing-Call-Reply)
+ message with the matching RTP AVP (if needed). The initiator needs
+ to validate that it can supply the requirements derived from the
+ received RTP AVP.
+
+ The two peers MUST agree on the values in the TDM PW AVP:
+
+ 1. Bit Rate values MUST be equal on both sides. If they are
+ different, the connection will be rejected with Result Code 30 and
+ Error Code 1.
+
+ 2. In the case of trunk-specific CESoPSN with CAS, the trunk type (as
+ encoded in the CAS bits of the TDM AVP) MUST be the same for the
+ two sides. Otherwise, the connection will be rejected with Result
+ Code 30 and Error Code 2.
+
+ 3. If one side does not support the Payload Bytes value proposed by
+ the other one, the connection will be rejected with Result Code 30
+ and Error Code 3.
+
+ 4. If one side cannot send the RTP header as requested by the other
+ side, the connection will be rejected with Result Code 30 and
+ Error Code 4.
+
+ 5. If one side can send the RTP header but not with the requested
+ timestamp clock frequency, the connection will be rejected with
+ Result Code 30 and Error Code 5.
+
+ If CE signaling for a CESoPSN basic PW is transported in a separate
+ PW instance, then the two PW instances:
+
+ 1. MUST use the same PW type.
+
+ 2. MUST use the same values in all the fields of the TDM AVP
+ excluding the SP field, which must be set to '01' for the TDM data
+ PW and to '10' for the PW carrying CE application signaling.
+
+ 3. MUST both either use or not use the RTP header (and, accordingly,
+ include or not include the RTP AVP).
+
+
+
+
+
+
+
+
+
+
+Vainshtein & Galtzur Standards Track [Page 8]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+4. IANA Considerations
+
+ IANA assigned the following values according to this document:
+
+ New L2TPv3 Pseudowire Types:
+
+ 0x0011 - Structure-agnostic E1 circuit
+ 0x0012 - Structure-agnostic T1 (DS1) circuit
+ 0x0013 - Structure-agnostic E3 circuit
+ 0x0014 - Structure-agnostic T3 (DS3) circuit
+ 0x0015 - CESoPSN basic mode
+ 0x0017 - CESoPSN TDM with CAS
+
+ Note that the values listed match the values defined in [RFC4446] for
+ the MPLS Pseudowire Types.
+
+ New Attribute-Value Pair IDs:
+
+ 99 - TDM Pseudowire AVP
+ 100 - RTP AVP
+
+ New Result Codes for the CDN message:
+
+ 30 - Result Code to indicate connection was refused because of TDM
+ PW parameters. The Error Code indicates the problem.
+
+ New TDM PW specific Error Codes, to be used with 30 Result Code for
+ the CDN message:
+
+ This is a new registry for IANA to maintain within the Result Code
+ AVP (Attribute Type 1) Values. Additional values may be assigned by
+ Expert Review [RFC5226].
+
+ 0 - Reserved.
+ 1 - Bit Rate values disagree.
+ 2 - Different trunk types in the case of trunk-specific CESoPSN
+ with CAS.
+ 3 - Requested payload size too big or too small.
+ 4 - RTP header cannot be generated.
+ 5 - Requested timestamp clock frequency cannot be generated.
+
+5. Congestion Control
+
+ The congestion considerations from [RFC4553] and [RFC5086] apply
+ respectively to the structure-agnostic and CESoPSN modes of this
+ specification.
+
+
+
+
+
+Vainshtein & Galtzur Standards Track [Page 9]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+6. Security Considerations
+
+ This document specifies only the L2TPv3-based control plane for setup
+ of TDM PWs. Within this scope, there are no additional security
+ considerations in addition to those discussed in [RFC3931].
+
+ Common data plane security considerations for the TDM PWs have been
+ discussed in some detail in both [RFC4553] and [RFC5086]. On top of
+ these, the L2TPv3-based data plane provides additional security
+ mechanisms based on the usage of cookies.
+
+7. Acknowledgements
+
+ The authors want to thank Carlos Pignataro, Ignacio Goyret, and
+ Yaakov Stein for careful review and useful suggestions.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
+ "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC
+ 3931, March 2005.
+
+ [RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
+ Agnostic Time Division Multiplexing (TDM) over Packet
+ (SAToP)", RFC 4553, June 2006.
+
+ [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
+ P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
+ Circuit Emulation Service over Packet Switched Network
+ (CESoPSN)", RFC 5086, December 2007.
+
+8.2. Informative References
+
+ [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+ Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+ [RFC5087] Y(J). Stein, Shashoua, R., Insler, R., and M. Anavi, "Time
+ Division Multiplexing over IP (TDMoIP)", RFC 5087,
+ December 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+
+
+Vainshtein & Galtzur Standards Track [Page 10]
+
+RFC 5611 TDM over L2TPv3 August 2009
+
+
+ [RFC5287] Vainshtein, A. and Y(J). Stein, "Control Protocol
+ Extensions for the Setup of Time-Division Multiplexing
+ (TDM) Pseudowires in MPLS Networks", RFC 5287, August
+ 2008.
+
+Authors' Addresses
+
+ Alexander Vainshtein,
+ ECI Telecom,
+ 30 ha-Sivim St. PO Box 500,
+ Petah-Tiqva 49517, Israel
+ EMail: Alexander.Vainshtein@ecitele.com
+
+
+ Sharon Galtzur
+ Rebellion Inc.
+ 29 The Chilterns, Gloucester Green,
+ Oxford, OX1 2DF, UK
+ EMail: sharon.galtzur@rebellion.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vainshtein & Galtzur Standards Track [Page 11]
+