One document matched: draft-ieft-l2tpext-tdm-01.txt
Differences from draft-ieft-l2tpext-tdm-00.txt
L2TP TDM July 2005
Network Working Group
Internet Draft S. Galtzur
Document: draft-ieft-l2tpext-tdm-01.txt Axerra Networks
Expires: January 2006 July 2005
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 [PWE3-SATOP] and structure-
aware [PWE3-CESoPSN], [PWE3-TDMoIP] 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 handle
these packets.
In this document we refer to the data plane as 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].
Galtzur Expires - January 2006 [Page 1]
L2TP TDM July 2005
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]..........................4
2.3 Changes in the Control Connection AVPs.....................5
2.4 Changes in the Session Connection AVPs.....................5
3. Creation of the TDM Pseudowire Session.........................5
4. IANA Considerations............................................6
Security Considerations...........................................6
Copyright notice..................................................7
Normative references..............................................8
Acknowledgments...................................................8
Author's Addresses................................................8
1. Introduction
This document defines extensions to the Layer Two Tunneling Protocol
(L2TP) for support of structure-agnostic [PWE3-SATOP] and structure-
aware [PWE3-CESoPSN], [PWE3-TDMoIP] pseudowires.
2. L2TP Extension
The L2TP Control Connection is responsible for 3 main operations:
1. Establishment and validation of session.
2. Ending (tearing down) of session.
3. Transferring of End Point status.
Tearing down of session is identical to [RFC3931].
[PWE3-CESoPSN] and [PWE3-SATOP] describe how to transfer the END
Point status via the Data Plane. This is therefore RECOMMENDED to not
use the Set-Link-Info (SLI) described in [RFC3931].
The next sections describe the extensions to the L2TP for
establishment and validation of TDM Pseudowire sessions.
There are 2 new AVPs for the Session Connection Messages. One AVP
describe the TDM Pseudowire attributes. The second AVP describe the
RTP attributes for this TDM Pseudowire.
Galtzur Expires - January 2006 [Page 2]
L2TP TDM July 2005
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 [TBD] |R|T|F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Bit Rate 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 is unambiguously derived from the PW Type.
2. Only the following values MUST be specified for structure-agnostic
emulation (see [PWE3-SATOP]:
a. Structure-agnostic E1 emulation - 32
b. Structure-agnostic T1 emulation:
1. MUST be set to 24 for the basic emulation mode
2. 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 the number of DS0 channels in the corresponding attachment
circuit.
Note: for Structure-agnostic T1 emulation the value 24 does not
indicate the exact bit rate, and is used for convenience only.
Payload Bytes has been initially defined for 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. For Structure-agnostic emulation the payload type can be any
value.
2. For CESoPSN PWs:
a. The specified value MUST be an integer multiple of number of
DS0 channels in the corresponding attachment circuit.
b. For trunk-specific NxDS0 with CAS, (Payload Bytes/number of DS0
channels) must be an integer factor of the number of frames per
corresponding trunk multiframe
3. For TDMoIP the Payload Bytes must be an integer multiple of 48
Galtzur Expires - January 2006 [Page 3]
L2TP TDM July 2005
The R bit defines the present of the RTP header. If the R bit is 1
then the RTP header is present and the RTP AVP MUST appear. If the R
bit is zero then the RTP header is not used.
The T bit is ignored and MUST be set to zero.
The F bit indicates fragmentation when sending multiframe. The F bit
MUST be zero for all TDM PWs Types excluding trunk-specific NxDS0
services with CAS using the CESoPSN encapsulation. In case of these
services, the F bit MUST be set if the payload size specified value
differs from the number of frames per trunk multiframe.
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 [TBD] |D| PT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Timestamp Clock Frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MUST appear only if the RTP header is used.
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 differential time stamping in the RTP header. If
the D bit is set to 1 then the time stamping is differential.
Otherwise absolute time stamping is used. Differential mode can be
used only if both sides use RTP and use differential time stamping.
PT is the payload type expected in the RTP header. Value of zero
indicates that the payload type is ignored and will not be used to
detect malformed packets.
Timestamp Clock Frequency is the clock frequency used for the time
stamping in 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
via the cookies, if the cookie length is larger then zero the SSRC
SHOULD be zero.
Galtzur Expires - January 2006 [Page 4]
L2TP TDM July 2005
2.3 Changes in the Control Connection AVPs
Control Connection that support TDM MUST add the appropriate PW Type
value to the list in the Pseudowire Capabilities List AVP. The exact
value is TBD by IANA and is 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 [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. CESoPSN basic mode - TBA by IANA
b. TDMoIP basic mode - TBA by IANA
c. CESoPSN service with CAS - TBA by IANA
d. TDMoIP with CAS - TBA 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.
3. Creation of the TDM Pseudowire Session
When LCCE wants to open a Session for TDM PW it should include the
TDM PW AVP and the RTP AVP (if needed) in the ICRQ or OCRQ message.
The LCCE peer must validate that TDM PW AVP and make sure it can
supply the requirements derived from the RTP AVP (if any exist). If
the peer agrees with the CESoPSN AVP it will send an appropriate ICRP
or OCRP message with RTP AVP (if needed). The Initiator need to
validate that it can supply the requirements derived from the
received RTP AVP.
Galtzur Expires - January 2006 [Page 5]
L2TP TDM July 2005
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. 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-2.
3. If one side cannot send RTP header requested by the other side,
the connection will be rejected with return code RC-TBD-1 and
error code EC-TBD-3.
4. 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-4.
4. IANA Considerations
This draft requires assignment of the following values by IANA:
PW types listed in Section 2.1 above.
New attribute value pair IDs:
1. AVP-TBD-1 - TDM Pseudo-wire AVP
2. AVP-TBD-2 - RTP AVP
New return codes and error codes:
1. RC-TBD-1 - return code to indicate connection refused because of
TDM PW parameters. The exact error code is as follows.
2. EC-TBD-1 - indicate Bit Rate values disagree.
3. EC-TBD-2 - requested payload size too big or too small.
4. EC-TBD-3 - RTP header cannot be generated.
5. EC-TBD-4 - requested timestamp clock frequency cannot be
generated.
Security Considerations
There are no additional security considerations on top of the ones
discussed in [RFC3931]
Galtzur Expires - January 2006 [Page 6]
L2TP TDM July 2005
Copyright notice
Copyright (C) The Internet Society (2005).
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 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.
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.
Galtzur Expires - January 2006 [Page 7]
L2TP TDM July 2005
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
[PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit
Emulation Service over Packet Switched Network
(CESoPSN), Work in progress, July 2005, draft-ietf-
pwe3-cesopsn-03.txt
[PWE3-SATOP] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over
Packet (SAToP), Work in Progress, July 2005,
draft-ietf-pwe3-satop-02.txt
[PWE3-TDMoIP] Y. Stein et al, TDM over IP, Work in progress, draft-
ietf-pwe3-tdmoip-03.txt, February 2005.
[PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo
Wire Edge to Edge Emulation (PWE3), Work in progress,
June 2005, draft-ietf-pwe3-iana-allocation-11.txt
Acknowledgments
I thank Alexander ("Sasha") Vainshtein for reviewing this text.
Author's Addresses
Sharon Galtzur
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
Email: sharon@axerra.com
Galtzur Expires - January 2006 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 09:49:43 |