Skip to main content

Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires
RFC 5611

Revision differences

Document history

Date Rev. By Action
2015-10-14
07 (System) Notify list changed from l2tpext-chairs@ietf.org, draft-ietf-l2tpext-tdm@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2009-08-19
07 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2009-08-19
07 Amy Vezza [Note]: 'RFC 5611' added by Amy Vezza
2009-08-18
07 (System) RFC published
2009-07-02
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-07-02
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-07-02
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-07-01
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-06-23
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2009-06-22
07 (System) IANA Action state changed to In Progress
2009-06-22
07 Amy Vezza IESG state changed to Approved-announcement sent
2009-06-22
07 Amy Vezza IESG has approved the document
2009-06-22
07 Amy Vezza Closed "Approve" ballot
2009-06-19
07 (System) Removed from agenda for telechat - 2009-06-18
2009-06-18
07 Cindy Morgan State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Cindy Morgan
2009-06-18
07 Adrian Farrel
[Ballot comment]
Sorry to raise a late comment...

In section 2.1
  1)Only the following values MUST be specified for structure-
    agnostic emulation …
[Ballot comment]
Sorry to raise a late comment...

In section 2.1
  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 
        ii) MUST be set to 25 for the "Octet-aligned T1"
            mode
    c) Structure-agnostic E3 emulation  - 535
    d) Structure-agnostic T3 emulation  - 699

I cannot parse this. Does the "MUST" apply to future specifications? I.e., is it an instruction to IANA? Or are you trying to say...

  For structure-agnostic emulation, this parameter MUST
  be set to one of the following values.
2009-06-18
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-06-17
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-06-15
07 Ralph Droms Placed on agenda for telechat - 2009-06-18 by Ralph Droms
2009-06-15
07 Ralph Droms State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ralph Droms
2009-06-15
07 Ralph Droms
This document has been through IESG review and all DISCUSSes have been resolved.  A new IETF Last Call was requested because of a downref that …
This document has been through IESG review and all DISCUSSes have been resolved.  A new IETF Last Call was requested because of a downref that was not explicitly called out in the previous Last Call.  No response was received to the new Last Call, so I'm hoping no one will mind if we take 30 seconds to approve the doc during this week's telechat.
2009-06-11
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-06-10
07 Amanda Baber
IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "Layer Two Tunneling Protocol (L2TP)" registry at
http://www.iana.org/assignments/l2tp-parameters

=====
[sub-registry …
IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "Layer Two Tunneling Protocol (L2TP)" registry at
http://www.iana.org/assignments/l2tp-parameters

=====
[sub-registry "Control Message Attribute Value Pairs"]

NEW:

Attribute
Type Description Reference
--------- ------------------ ---------
99 TDM Pseudowire AVP [RFC-l2tpext-tdm-07]
100 RTP AVP [RFC-l2tpext-tdm-07]


=====
[sub-registry "Result Code AVP (Attribute Type 1) Values"

NEW:

Defined Result Code values for the CDN message are:

30 - Connection refused because of TDM PW parameters [RFC-l2tpext-tdm-07]


=====
[sub-registry "Result Code AVP (Attribute Type 1) Values"

OLD:

General Error Codes
...
12 - TSA busy. This identifies an error condition
[draft-ietf-l2tpext-tunnel-switching-06.txt]
explicitly in the multi-TSA environment.


NEW:

General Error Codes
...
12 - TSA busy. This identifies an error condition
[draft-ietf-l2tpext-tunnel-switching-06.txt]
explicitly in the multi-TSA environment.


TDM PW Specific error codes, to be used with 30 result code for the
CDN message [RFC-l2tpext-tdm-07]

0 - Reserved [RFC-l2tpext-tdm-07]
1 - Bit Rate values disagree. [RFC-l2tpext-tdm-07]
2 - Different trunk types in the case of
trunk- specific CESoPSN with CAS [RFC-l2tpext-tdm-07]
3 - Requested payload size too big or too small [RFC-l2tpext-tdm-07]
4 - RTP header cannot be generated. [RFC-l2tpext-tdm-07]
5 - Requested timestamp clock frequency cannot be
generated [RFC-l2tpext-tdm-07]


=====
[sub-registry "L2TPv3 Pseudowire Types"]

NEW:

Value Description Reference
------ ---------------------------------- ---------
0x0011 Structure-agnostic E1 circuit [RFC-l2tpext-tdm-07]
0x0012 Structure-agnostic T1 (DS1) circuit [RFC-l2tpext-tdm-07]
0x0013 Structure-agnostic E3 circuit [RFC-l2tpext-tdm-07]
0x0014 Structure-agnostic T3 (DS3) circuit [RFC-l2tpext-tdm-07]
0x0015 CESoPSN basic mode [RFC-l2tpext-tdm-07]
0x0017 CESoPSN TDM with CAS [RFC-l2tpext-tdm-07]
2009-05-29
07 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2009-05-28
07 Cindy Morgan Last call sent
2009-05-28
07 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2009-05-28
07 Ralph Droms State Changes to Last Call Requested from IESG Evaluation::AD Followup by Ralph Droms
2009-05-28
07 Ralph Droms Last Call was requested by Ralph Droms
2009-05-28
07 Ralph Droms [Ballot Position Update] New position, Yes, has been recorded by Ralph Droms
2009-04-22
07 Pasi Eronen [Ballot comment]
2009-04-22
07 Pasi Eronen [Ballot discuss]
(Updated for version -07) RFC 5086 is a normative downref,
so it needs to be mentioned during IETF Last Call.
2009-04-21
07 (System) New version available: draft-ietf-l2tpext-tdm-07.txt
2009-04-07
07 Ralph Droms Responsible AD has been changed to Ralph Droms from Mark Townsley
2009-02-06
07 Mark Townsley Sent email to sasha to check on normative ref issue, etc.
2009-02-06
07 Mark Townsley Note field has been cleared by Mark Townsley
2009-01-15
07 Cindy Morgan State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead by Cindy Morgan
2009-01-15
07 Mark Townsley [Note]: 'Need to look into normative reference issue - and whether this will cause a downref or not.' added by Mark Townsley
2009-01-15
07 Pasi Eronen
[Ballot discuss]
I have reviewed draft-ietf-l2tpext-tdm-06. Overall, the document
looks good, but I have the following concerns that I'd like to discuss
before recommending approval …
[Ballot discuss]
I have reviewed draft-ietf-l2tpext-tdm-06. Overall, the document
looks good, but I have the following concerns that I'd like to discuss
before recommending approval of the document:

- Section 4 says the IANA policy for unassigned values is "Expert
Review", but does not list the registries IANA is supposed to create.

- It seems RFCs 4553 and 5086 should be normative references (they
describe e.g. the packet formats used, so they're not just optional
background information). RFC 5086 would be a downref.
2009-01-15
07 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2009-01-15
07 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-01-15
07 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2009-01-15
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2009-01-15
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2009-01-15
07 Jari Arkko [Ballot comment]
Section 1:

> signaling packets). However, the order of the CESoPSN Control Word

The acronym needs to be expanded.
2009-01-15
07 Lars Eggert
[Ballot comment]
Section 1., paragraph 3:
>    Setup and maintenance of TDM PWs in MPLS networks using LDP is
>    described in []. …
[Ballot comment]
Section 1., paragraph 3:
>    Setup and maintenance of TDM PWs in MPLS networks using LDP is
>    described in [].

  Missing reference.


Section 1., paragraph 2:
>    Setup of structure-aware TDM pseudowires using encapsulations
>    described in [RFC5087] has been left for further study.

  In that case, the document title should reflect that. Maybe "Layer Two
  Tunneling Protocol - Setup of Structure-Agnostic TDM Pseudowires"? The
  RFC Editor will also likely ask you to expand the TDM acronym in the
  title (and many of the other acronyms you're using.)
2009-01-15
07 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2009-01-14
07 Lars Eggert
[Ballot comment]
Section 1., paragraph 2:
>    Setup of structure-aware TDM pseudowires using encapsulations
>    described in [RFC5087] has been left …
[Ballot comment]
Section 1., paragraph 2:
>    Setup of structure-aware TDM pseudowires using encapsulations
>    described in [RFC5087] has been left for further study.

  In that case, the document title should reflect that. Maybe "Layer Two
  Tunneling Protocol - Setup of Structure-Agnostic TDM Pseudowires"? The
  RFC Editor will also likely ask you to expand the TDM acronym in the
  title (and many of the other acronyms you're using.)
2009-01-14
07 Lars Eggert
[Ballot discuss]
Section 1., paragraph 3:
>    Setup and maintenance of TDM PWs in MPLS networks using LDP is
>    described in []. …
[Ballot discuss]
Section 1., paragraph 3:
>    Setup and maintenance of TDM PWs in MPLS networks using LDP is
>    described in [].

  DISCUSS: Missing reference. (I'm only making this a discuss in case
  this would be a missing normative reference. We can clear this up on
  the call, I think.)
2009-01-14
07 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2009-01-14
07 Pasi Eronen
[Ballot comment]
Section 1 says "Setup and maintenance of TDM PWs in MPLS networks
using LDP is described in []" -- this seems to be …
[Ballot comment]
Section 1 says "Setup and maintenance of TDM PWs in MPLS networks
using LDP is described in []" -- this seems to be missing the
actual reference.
2009-01-14
07 Pasi Eronen
[Ballot discuss]
I have reviewed draft-ietf-l2tpext-tdm-06. Overall, the document
looks good, but I have the following concerns that I'd like to discuss
before recommending approval …
[Ballot discuss]
I have reviewed draft-ietf-l2tpext-tdm-06. Overall, the document
looks good, but I have the following concerns that I'd like to discuss
before recommending approval of the document:

- A quick question about the "Bit Rate" field of TDM PW AVP: other
related RFCs (RFC 5287, 4842) use a 32-bit field for bit rate, and
a 16-bit field  can't express a bit rate larger than ~4 Gbps. Is
this enough?

- Section 4 says the IANA policy for unassigned values is "Expert
Review", but does not list the registries IANA is supposed to create.

- It seems RFCs 4553 and 5086 should be normative references (they
describe e.g. the packet formats used, so they're not just optional
background information). RFC 5086 would be a downref.
2009-01-14
07 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2009-01-14
07 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-01-14
07 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2009-01-14
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-01-14
07 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-01-13
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-01-13
07 Magnus Westerlund
[Ballot comment]
There is quite a lot of non-expanded acronyms in the initial part of the document.

Especially these ones needs expanding and possibly references: …
[Ballot comment]
There is quite a lot of non-expanded acronyms in the initial part of the document.

Especially these ones needs expanding and possibly references:

Conventions:
In this document we refer to control plane as the packets that
  contain control information (via AVP) and the mechanism that handles
  these packets. 

Section 1: Is RTP (RFC 3550) here?
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.

Note that there is an acronym overloading here with the word (AVP) as that has one meaning in RTP talk (Audio/video Profile) and another in this document. So RTP AVP in section 2.2 has the potential to be somewhat confusing.
2009-01-12
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-01-12
07 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2009-01-12
07 Mark Townsley Ballot has been issued by Mark Townsley
2009-01-12
07 Mark Townsley Created "Approve" ballot
2009-01-12
07 Mark Townsley Placed on agenda for telechat - 2009-01-15 by Mark Townsley
2008-11-28
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-11-24
07 Amanda Baber
IANA Last Call comments:

IESG Note: Expert Reviewer Assignment Required for Action 4.

Action 1:

Upon approval of this document, the IANA will make the …
IANA Last Call comments:

IESG Note: Expert Reviewer Assignment Required for Action 4.

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "L2TPv3 Pseudowire Types" registry at
http://www.iana.org/assignments/l2tp-parameters

TBD(0x0011) (SAToP-E1) - Structure-agnostic E1 circuit
[RFC-l2tpext-tdm-06]
TBD(0x0012) (SAToP-T1) - Structure-agnostic T1 (DS1) circuit
[RFC-l2tpext-tdm-06]
TBD(0x0013) (SAToP-E3) - Structure-agnostic E3 circuit
[RFC-l2tpext-tdm-06]
TBD(0x0014) (SAToP-T3) - Structure-agnostic T3 (DS3) circuit
[RFC-l2tpext-tdm-06]
TBD(0x0015) (CESoPSN-Basic) - CESoPSN basic mode
[RFC-l2tpext-tdm-06]
TBD(0x0017) (CESoPSN-CAS) - CESoPSN TDM with CAS
[RFC-l2tpext-tdm-06]


Action 2:

Upon approval of this document, the IANA will make the following
assignments in the "Control Message Attribute Value Pairs"
registry at
http://www.iana.org/assignments/l2tp-parameters

Attribute
Type Description Reference
--------- ------------------ ---------
[TBD] TDM Pseudowire AVP [RFC-l2tpext-tdm-06]
[TBD] RTP AVP [RFC-l2tpext-tdm-06]


Action 3:

Upon approval of this document, the IANA will make the following
assignment in the "Result Code AVP (Attribute Type 1) Values"
registry at
http://www.iana.org/assignments/l2tp-parameters

Defined Result Code values for the CDN message are:

[TBD] - connection refused because of TDM PW parameters. The error
code indicates the problem. [RFC-l2tpext-tdm-06]


Action 4:

Upon approval of this document, the IANA will create the
following sub-registry at
http://www.iana.org/assignments/l2tp-parameters

Registry Name: Error codes for use with the TDP PW refusal
Registration Procedures: Expert Review
Initial contents of this sub-registry will be:

1 - Bit Rate values disagree. [RFC-l2tpext-tdm-06]
2 - Different trunk types in the case of trunk- [RFC-l2tpext-tdm-06]
specific CESoPSN with CAS
3 - Requested payload size too big or too small. [RFC-l2tpext-tdm-06]
4 - RTP header cannot be generated. [RFC-l2tpext-tdm-06]
5 - Requested timestamp clock frequency cannot be [RFC-l2tpext-tdm-06]
generated


We understand the above to be the only IANA Actions for this document.
2008-11-14
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-11-14
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Catherine Meadows
2008-11-14
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Catherine Meadows
2008-11-13
07 Mark Townsley Last Call was requested by Mark Townsley
2008-11-13
07 Mark Townsley Last Call was requested by Mark Townsley
2008-11-13
07 Mark Townsley State Changes to Last Call Requested from AD Evaluation by Mark Townsley
2008-11-13
07 (System) Ballot writeup text was added
2008-11-13
07 (System) Last call text was added
2008-11-13
07 (System) Ballot approval text was added
2008-11-13
07 Mark Townsley State Changes to AD Evaluation from Publication Requested by Mark Townsley
2008-11-11
07 Cindy Morgan
    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of …
    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Yes. Carlos Pignataro will be the WG Document Shepherd for this
document.


    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has been reviewed in the l2tpext WG. Further detailed
review was performed by Carlos Pignataro and Ignacio Goyret. Finally,
Yaakov Stein reviewed the document as a key non-WG member, active in
PWE3, and co-author of most TDM-related RFCs included as References.
All review comments have been adequately addressed.

There are no concerns about the extent of the reviews.


    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No, we don't believe there is any need for additional review from other
areas.


    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

All concerns raised in the mailing list have been addressed in the
revision -06 of the document. To my knowledge, there aren't any
outstanding issues or concerns.


    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There have been no dissenting voices during review and/or WGLC.


    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.


    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Yes. The document checks idnits without any issues found:



    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references are properly split into Normative and Informative. All
the references are already published RFCs, and there are no downward
references.


    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section is consistent with the body of the
documents, and has been enhanced for clarity as part of a WGLC comment.
All reservation requests are from
. There are suggested
values only for the "L2TPv3 Pseudowire Types", consistent with the IANA
registry. These suggested values are provided for consistency with a
corresponding pwe3-parameters number space.


    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no sections on this document using any formal language.


    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

This document describes transport of TDM bit-streams over the Layer Two
Tunneling Protocol Version 3 (L2TPv3). It describes extensions of L2TPv3
for the setup and maintenance of structure-agnostic and structure-aware
TDM Pseudowires, to transport TDM bit-streams over an IP network.


          Working Group Summary
            Was there anything in WG process that is worth noting? For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

There is consensus in the WG to publish this document.


          Document Quality
            Are there existing implementations of the protocol? Have a
            significant number of vendors indicated their plan to
            implement the specification? Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues? If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)? In the case of a Media Type
            review, on what date was the request posted?

The l2tpext WG has reviewed this document. All concerns raised during
review and last call have been addressed.

Yaakov Stein performed a very detailed review during WGLC, with the
conclusion that "this ID looks ready for publication" at
.

This document defines an application of L2TPv3 to transport another type
of traffic, and is consistent with corresponding PWE3 documents.

Carlos Pignataro is the WG shepherd for this document.
2008-11-11
07 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-10-29
06 (System) New version available: draft-ietf-l2tpext-tdm-06.txt
2008-06-19
05 (System) New version available: draft-ietf-l2tpext-tdm-05.txt
2007-11-20
04 (System) New version available: draft-ietf-l2tpext-tdm-04.txt
2007-03-05
03 (System) New version available: draft-ietf-l2tpext-tdm-03.txt