doc: Add RFC documents

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