One document matched: draft-ietf-l2tpext-tdm-06.txt
Differences from draft-ietf-l2tpext-tdm-05.txt
TDM over L2TPv3 October 2008
Network Working Group A. Vainshtein
Internet Draft ECI Telecom
Document: draft-ietf-l2tpext-tdm-06.txt S. Galtzur
Rebellion
Creation Date: October 15, 2008
Intended Status: Proposed Standard
Expires: April 2009
Layer Two Tunneling Protocol - Setup of TDM Pseudowires
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/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 extensions to the Layer Two Tunneling Protocol
(L2TP) for support of structure-agnostic and structure-aware TDM
pseudowires.
Conventions used in this document
In this document we refer to control plane as the packets that
contain control information (via AVP) and the mechanism that handles
these packets.
In this document we refer to the data plane as the packets that
contain transported user data.
Vainshtein and Galtzur Expires - April 2009 [Page 1]
TDM over L2TPv3 October 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 [RFC2119].
Table of Contents
1. Introduction...................................................2
2. L2TP Extension.................................................2
2.1 TDM PW AVP (ICRQ, OCRQ)...................................3
2.2 RTP AVP (ICRQ, OCRQ, ICRP, OCRP)..........................5
2.3 Changes in the Control Connection AVPs.....................6
2.4 Changes in the Session Connection AVPs.....................6
3. Creation of the TDM Pseudowire Session.........................6
4. IANA Considerations............................................7
5. Congestion Control.............................................8
6. Security Considerations........................................8
7. Acknowledgements...............................................8
Copyright notice..................................................9
Normative references.............................................11
Informative references...........................................11
Authors' Addresses...............................................11
1. Introduction
This document defines extensions to the Layer Two Tunneling Protocol
Version 3(L2TPv3) for support of structure-agnostic [RFC4553] and
structure-aware [RFC5086] TDM pseudowires. Structure-agnostic
encapsulation of TDM bit-streams over L2TPv3 is described in
[RFC4553], Figure 2b, and structure-aware encapsulation - 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 encapsulations
described in [RFC5087] has been left for further study.
Setup and maintenance of TDM PWs in MPLS networks using LDP is
described in [].
2. L2TP Extension
The L2TP 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.
Vainshtein and Galtzur Expires - April 2009 [Page 2]
TDM over L2TPv3 October 2008
Tearing down of session for a TDM pseudowire performed as described
in 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 AVP MUST be present in
the ICRQ/ICRP 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 L2TP 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.
2.1 TDM PW 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 (AVP-TBA-1) | 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) 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 for the basic mode
Vainshtein and Galtzur Expires - April 2009 [Page 3]
TDM over L2TPv3 October 2008
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 Bit Rate Interface Attribute as defined
in [RFC5287].
The Payload Bytes field contains the value representing the number of
the 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 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 following:
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 e CESoPSN PW carrying both TDM data and
signaling packets
4) Set to '00' for 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:
1) For trunk-specific CESoPSN with CAS these bits MUST be set to:
a) '01' in the case of an E1 trunk
Vainshtein and Galtzur Expires - April 2009 [Page 4]
TDM over L2TPv3 October 2008
b) '10' in the case of a T1/ESF trunk
c) '11' in the case of a T1/SF trunk.
2) MUST be set to '00' for all the other TDM pseudowire types.
2.2 RTP 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 (AVP-TBA-2) |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., in [RFC4553],
Section 4.3.2. 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 as SAToP/CESoPSN encapsulation over
IPv4/IPv6 PSN with L2TPv3 demultiplexing in [RFC4553] and
[RFC5086] respectively.
o If the C bit is set to 0 the RTP header appears before the
control word. This mode described as the old mode of the
SAToP/CESoPSN encapsulation over L2TPv3 in [RFC4553], Appendix
A, and [RFC5086], Annex C, respectively.
PT is the payload type expected in the RTP header. A value of zero
indicates that the receiver shall not check payload type to detect
malformed packets.
Vainshtein and Galtzur Expires - April 2009 [Page 5]
TDM over L2TPv3 October 2008
Timestamp Clock Frequency is the clock frequency used for the time
stamping in units of 8 KHz.
SSRC indicates the expected value of SSRC ID in the RTP header. A
zero in this field means that 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 zero the SSRC
SHOULD be zero.
2.3 Changes in the Control Connection 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 Connection AVPs
PW Type AVP should be set to one of the following values:
1. Structure-agnostic emulation [RFC4553] of:
a. E1 circuits - TBA-SAToP-E1 by IANA
b. T1 circuits - TBA-SAToP-T1 by IANA
c. E3 circuits - TBA-SAToP-E3 by IANA
d. T3 circuits - TBA-SAToP-T3 by IANA
2. Structure-aware emulation [RFC5086] of:
a. CESoPSN basic mode - TBA-CESoPSN-Basic by IANA
b. Trunk-specific CESoPSN service with CAS - TBA-CESoPSN-
CAS by IANA
TDM pseudowires use their own control word. Therefore the L2-
Specific Sublayer AVP MUST either be omitted or set to zero.
TDM pseudowires use their own sequencing. Therefore the Data
Sequencing AVP MUST either be omitted or set to zero.
Note: The Control Word (CW) used in the SAToP and CESoPSN
encapsulations over L2TPv3 effectively represents a dedicated L2-
Specific Sub-layer.
3. Creation of the TDM Pseudowire Session
When LCCE wants to open a Session for 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 message. The LCCE peer must validate
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 message with the matching
RTP AVP (if needed). The Initiator need to validate that it can
supply the requirements derived from the received RTP AVP.
Vainshtein and Galtzur Expires - April 2009 [Page 6]
TDM over L2TPv3 October 2008
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 return code
RC-TBD-1 and error code EC-TBD-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 return code RC-TBD-1 and error code EC-TBD-2.
3. If one side does not support the payload bytes value proposed
by the other one, the connection will be rejected with return
code RC-TBD-1 and error code EC-TBD-3.
4. If one side cannot send RTP header as requested by the other
side, the connection will be rejected with return code RC-
TBD-1 and error code EC-TBD-4.
5. If one side can send RTP header but not with the requested
timestamp clock frequency, the connection will be rejected
with return code RC-TBD-1 and error code EC-TBD-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 use or not use RTP header (and accordingly,
include or not include the RTP AVP).
4. IANA Considerations
This draft requires assignment of the following values by IANA:
New L2TPv3 Pseudowire Types:
L2TPv3 Pseudowire Types:
0x0011 (TBA-SAToP-E1) - Structure-agnostic E1 circuit
0x0012 (TBA-SAToP-T1) - Structure-agnostic T1 (DS1) circuit
0x0013 (TBA-SAToP-E3) - Structure-agnostic E3 circuit
0x0014 (TBA-SAToP-T3) - Structure-agnostic T3 (DS3) circuit
0x0015 (TBA-CESoPSN-Basic) - CESoPSN basic mode
0x0017 (TBA-CESoPSN-CAS) - CESoPSN TDM with CAS
Vainshtein and Galtzur Expires - April 2009 [Page 7]
TDM over L2TPv3 October 2008
Note that the values listed are suggested, to match with the values
defined in [RFC4446] for the MPLS Pseudowire Types.
New attribute value pair IDs:
1. AVP-TBD-1 - TDM Pseudowire AVP
2. AVP-TBD-2 - RTP AVP
New return codes for the CDN message:
1. RC-TBD-1 - return code to indicate connection refused
because of TDM PW parameters. The error code indicates the
problem.
New error codes, to be used with the RC-TDB-1 return code:
1. EC-TBD-1 - Bit Rate values disagree.
2. EC-TBD-2 - Different trunk types in the case of trunk-
specific CESoPSN with CAS
3. EC-TBD-3 - Requested payload size too big or too small.
4. EC-TBD-4 - RTP header cannot be generated.
5. EC-TBD-5 - Requested timestamp clock frequency cannot be
generated
Any values that are reserved or unassigned in this specification are
assignable by Expert Review [RFC5226].
5. Congestion Control
The congestion considerations from [RFC4553] and [RFC5086] apply
respectively to the structure-agnostic and CESoPSN modes of this
specification.
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 on top of 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 usage of cookies.
7. Acknowledgements
The authors want to thank Carlos Pignataro, Ignacio Goyret and Yaakov
Stein for careful review and useful suggestions.
Vainshtein and Galtzur Expires - April 2009 [Page 8]
TDM over L2TPv3 October 2008
Copyright notice
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.
Vainshtein and Galtzur Expires - April 2009 [Page 9]
TDM over L2TPv3 October 2008
IPR Validity Disclaimer
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.
Vainshtein and Galtzur Expires - April 2009 [Page 10]
TDM over L2TPv3 October 2008
Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC3931] J. Lau, M. Townsley, I. Goyret, Layer Two Tunneling
Protocol - Version 3 (L2TPv3), March 2005
Informative references
[RFC5086] A. Vainshtein et al, Structure-aware TDM Circuit
Emulation Service over Packet Switched Network
(CESoPSN), RFC 5086, December 2007
[RFC4553] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over
Packet (SAToP), RFC 4553, June 2006
[RFC5087] Y. Stein et al, TDM over IP, RFC 5087, December 2007.
[RFC4446] L. Martini, M. Townsley, IANA Allocations for Pseudo
Wire Edge to Edge Emulation (PWE3), RFC 4446,
April 2006
[RFC5287] A. Vainshtein, Y. Stein, Control Protocol Extensions
for Setup of TDM Pseudowires in MPLS Networks, RFC 5287,
August 2008
[RFC5226] T. Narten, H. Alvestrand, Guidelines for Writing an IANA
Considerations Section in RFCs, RFC 5226, May 2008
Authors' Addresses
Sharon Galtzur
Rebellion Inc.
29 The Chilterns, Gloucester Green,
Oxford, OX1 2DF, UK
Email: sharon.galtzur@rebellion.co.uk
Alexander Vainshtein,
ECI Telecom,
30 ha-Sivim St. PO Box 500,
Petah-Tiqva 49517, Israel
Email: Alexander.Vainshtein@ecitele.com
Vainshtein and Galtzur Expires - April 2009 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-21 23:06:01 |