Skip to main content

Time Division Multiplexing over IP (TDMoIP)
draft-ietf-pwe3-tdmoip-06

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2007-02-28
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-02-26
06 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2007-02-22
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-01-14
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-01-11
06 (System) IANA Action state changed to In Progress
2007-01-11
06 Amy Vezza IESG state changed to Approved-announcement sent
2007-01-11
06 Amy Vezza IESG has approved the document
2007-01-11
06 Amy Vezza Closed "Approve" ballot
2007-01-11
06 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2006-12-05
06 (System) New version available: draft-ietf-pwe3-tdmoip-06.txt
2006-11-13
06 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2006-11-08
06 (System) Request for Early review by SECDIR Completed. Reviewer: Paul Hoffman.
2006-11-02
06 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2006-10-31
06 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2006-10-31
06 Magnus Westerlund
[Ballot discuss]
section 4.1:

What about IPv6?

"The UDP ports MUST
      be manually configured, and either field may contain the PW label." …
[Ballot discuss]
section 4.1:

What about IPv6?

"The UDP ports MUST
      be manually configured, and either field may contain the PW label."

If understand this correctly, this IP + UDP header is actually used to get the packet to where it should end up. If that is the case, I think this descriptive language is a bit broken. Because the UDP ports must be selected in such a way that the packets will arrive correctly and that any ICMP messages will be correctly indicate the source. Thus the PW label can't be arbitary chosen, and should rather be defined by the destination tuple. There is also the issue with middleboxes (although unlikely on the path I expect pseudowires to be deployed) that must be considered, or at least warned for.

- Unknonw section

I am also missing a discussion on configuration of relevant paramters. There seem to be only one informative reference to [TDM-Control] where I would expect further discussion on the need to configure the different parts.
2006-10-30
06 Cullen Jennings
[Ballot discuss]
Please update on how RTP is used for timing only and why this makes any extension for RTP (including SRTP) not allowed. (Like …
[Ballot discuss]
Please update on how RTP is used for timing only and why this makes any extension for RTP (including SRTP) not allowed. (Like the RFC ed note  for draft-ietf-pwe3-cesopsn)
2006-10-30
06 Cullen Jennings
[Ballot discuss]
Please update on how RTP is used for timing only and why this makes any extension for RTP (including SRTP) not allowed. (Like …
[Ballot discuss]
Please update on how RTP is used for timing only and why this makes any extension for RTP (including SRTP) not allowed. (Like the RFC ed note  for draft-ietf-pwe3-cesopsn)
2006-10-13
06 (System) Removed from agenda for telechat - 2006-10-12
2006-10-12
06 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-10-12
06 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2006-10-12
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-10-12
06 Dan Romascanu
[Ballot comment]
This document should be consistent with the requirements and architecture defined in RFC3916 and RFC4197. RFC3916 includes in Section 6 a statement …
[Ballot comment]
This document should be consistent with the requirements and architecture defined in RFC3916 and RFC4197. RFC3916 includes in Section 6 a statement that 'Each PWE3 approach SHOULD provide some mechanisms for network operators to manage the emulated service' and then goes into more detailed requirements about how such mechanisms could be implemented. I am surprised about the lack of any managemement or operational considerations section in this document in order to show how the requirements in Section 6 of RFC3916 are supposed to be addressed.
2006-10-12
06 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner
2006-10-12
06 Magnus Westerlund
[Ballot discuss]
Section 3:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new …
[Ballot discuss]
Section 3:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new profile need to be created. However I do suspect that this is not at all necessary and already defined profiels can be used. The specification must be rewritten to be using the defined behaviors of RTP or define a profile.

Because if one are going to be using RTP, the control word MUST be defined as an RTP payload format for RTP. That requires one to do a bit more than what is currently written into this specification. For instructions on what to think when defining RTP payload formats please reviw:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-howto-00.txt

Please do also consider what usage of multiple SSRCs means in your context.

section 4.1:

What about IPv6?

"The UDP ports MUST
      be manually configured, and either field may contain the PW label."

If understand this correctly, this IP + UDP header is actually used to get the packet to where it should end up. If that is the case, I think this descriptive language is a bit broken. Because the UDP ports must be selected in such a way that the packets will arrive correctly and that any ICMP messages will be correctly indicate the source. Thus the PW label can't be arbitary chosen, and should rather be defined by the destination tuple. There is also the issue with middleboxes (although unlikely on the path I expect pseudowires to be deployed) that must be considered, or at least warned for.

- Unknonw section

I am also missing a discussion on configuration of RTP and othe relevant paramters. There seem to be only one informative reference to [TDM-Control] where I would expect further discussion on the need to configure the different parts.
2006-10-12
06 Magnus Westerlund
[Ballot discuss]
Section 3:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new …
[Ballot discuss]
Section 3:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new profile need to be created. However I do suspect that this is not at all necessary and already defined profiels can be used. The specification must be rewritten to be using the defined behaviors of RTP or define a profile.

Because if one are going to be using RTP, the control word MUST be defined as an RTP payload format for RTP. That requires one to do a bit more than what is currently written into this specification. For instructions on what to think when defining RTP payload formats please reviw:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-howto-00.txt

Please do also consider what usage of multiple SSRCs means in your context.

section 4.1:

What about IPv6?

"The UDP ports MUST
      be manually configured, and either field may contain the PW label."

If understand this correctly, this IP + UDP header is actually used to get the packet to where it should end up. If that is the case, I think this descriptive language is a bit broken. Because the UDP ports must be selected in such a way that the packets will arrive correctly and that any ICMP messages will be correctly indicate the source. Thus the PW label can't be arbitary chosen, and should rather be defined by the destination tuple. There is also the issue with middleboxes (although unlikely on the path I expect pseudowires to be deployed) that must be considered, or at least warned for.
2006-10-12
06 Magnus Westerlund
[Ballot comment]
Section 4.1:

  UDP Checksum (16 bits) is the checksum of UDP/IP header and data.  If
      not computed it must …
[Ballot comment]
Section 4.1:

  UDP Checksum (16 bits) is the checksum of UDP/IP header and data.  If
      not computed it must be set to zero.

Does there exist any other error checking of the packet? If not I would strongly recommend against setting the checksum to 0.
2006-10-12
06 Magnus Westerlund
[Ballot discuss]
Section 3:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new …
[Ballot discuss]
Section 3:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new profile need to be created. However I do suspect that this is not at all necessary and already defined profiels can be used. The specification must be rewritten to be using the defined behaviors of RTP or define a profile.

Because if one are going to be using RTP, the control word MUST be defined as an RTP payload format for RTP. That requires one to do a bit more than what is currently written into this specification. For instructions on what to think when defining RTP payload formats please reviw:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-howto-00.txt

Please do also consider what usage of multiple SSRCs means in your context.

section 4.1:

What about IPv6?
2006-10-12
06 Magnus Westerlund
[Ballot discuss]
Section 3:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new …
[Ballot discuss]
Section 3:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new profile need to be created. However I do suspect that this is not at all necessary and already defined profiels can be used. The specification must be rewritten to be using the defined behaviors of RTP or define a profile.

Because if one are going to be using RTP, the control word MUST be defined as an RTP payload format for RTP. That requires one to do a bit more than what is currently written into this specification. For instructions on what to think when defining RTP payload formats please reviw:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-howto-00.txt

Please do also consider what usage of multiple SSRCs means in your context.
2006-10-12
06 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund
2006-10-12
06 Brian Carpenter
[Ballot discuss]
From Gen-ART review by Joel Halpern:

After reading section 5.3 several times, I am still left
guessing as to what the actual payload …
[Ballot discuss]
From Gen-ART review by Joel Halpern:

After reading section 5.3 several times, I am still left
guessing as to what the actual payload format will be when
transporting HDLC data using TDMoIP.  I presume it is described here
somehwere, but I can't find it.

BC: Author agrees that reference to RFC 4618 is needed to fix this.
2006-10-12
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2006-10-12
06 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2006-10-11
06 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2006-10-11
06 Cullen Jennings
[Ballot comment]
The statement about customary practice is to operate jitter buffer half full would lead to much larger voice latency that would be needed …
[Ballot comment]
The statement about customary practice is to operate jitter buffer half full would lead to much larger voice latency that would be needed in most cases. I would like to talk to authors on what they mean by this - perhaps we are just talking past each other but as it is, it does not seem correct.
2006-10-11
06 Cullen Jennings
[Ballot discuss]
I don't think a specification should subset RTP in such a way that it eliminates every one of the RTP extensibility mechanism. I …
[Ballot discuss]
I don't think a specification should subset RTP in such a way that it eliminates every one of the RTP extensibility mechanism. I suggest making a slight change to the document to just allow RTP.

The document says that SRTP should not be used but I think this should change. Once of the key reasons for using SRTP existence is that it will achieve much better compression in cases exactly like this when coupled with an appropriate header compression mechanism.

I am also concerned that this subsets other protocols in a way that limits extensibility - for example, it does not look it allows IP options. It does not seem like the document has a need to subset protocols it does not define so my recommendation would be not to do that.

The advice in section 7.1 about insertion of packets seems like it will break some applications such as TTY/TDD, Fax, and modems. I think the advice should be not to do that unless the application can do the appropriate tone detection (such as CNG) to know that the data represents a voice call.
2006-10-11
06 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2006-10-11
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-10-11
06 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2006-10-11
06 Lars Eggert
[Ballot comment]
The document seems to lack a both a reference to RFC 2119 and the
  recommended RFC 2119 boilerplate, even if it appears …
[Ballot comment]
The document seems to lack a both a reference to RFC 2119 and the
  recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
  keywords.

  Why is this going for Informational?
2006-10-09
06 Amy Vezza State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza
2006-10-09
06 Brian Carpenter
[Ballot comment]
From discussion between Gen-ART reviewer Joel Halpern and Yakov Stein:

The introduction does not tell me what this document is
about.  A few …
[Ballot comment]
From discussion between Gen-ART reviewer Joel Halpern and Yakov Stein:

The introduction does not tell me what this document is
about.  A few sentences along the lines of the technical summary in
the tracker would help.

[YJS] The description is in the Abstract and hinted at in the first
paragraph
of the Introducton. I will add a few sentences to the first paragraph
to make this more clear.

-----------

The paragraph on SAToP in section 2.seems to characterize a
loss rate of one fifth of one percent as an "extremely reliable and
overprovisioned PSN."  While I do not want to get in to an argument
about what is acceptable, it is to be noted that even TCP will have
performance problems with a link with a 0.2% loss rate.  ISPs with
loss rates much lower than that are still not usually referred to as
"extremely reliable."  I would recommend simply removing the sentence.

[YJS] This number come up from two sources.
1) documents presented to the ITU question that worked in parallel
to PWE3 showing that this is indeed a kind of dividing line between
well-engineered networks and best-effort ones.
2) empirical results that the user experience of circuit emulation
with AIS substitiution drops at this level (see
draft-stein-pwe3-tdm-packetloss-01.txt
now expired).
In any case, we are continually asked to characterize when to
stop using SAToP and go over to one of the structure-aware methods.
This is as good a break-point as any.
For these reasons I would suggest keeping this sentence.

BC: I disagree. It's almost as though people working in the ITU
are wishing to characterize the Internet as horribly unreliable,
but that can't be true can it? Better to simply drop the
specific percentage, I think.
2006-10-09
06 Brian Carpenter
[Ballot discuss]
From Gen-ART review by Joel Halpern:

After reading section 5.3 several times, I am still left
guessing as to what the actual payload …
[Ballot discuss]
From Gen-ART review by Joel Halpern:

After reading section 5.3 several times, I am still left
guessing as to what the actual payload format will be when
transporting HDLC data using TDMoIP.  I presume it is described here
somehwere, but I can't find it.

[YJS] It is compliant with draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt.
If this becomes an RFC before publication of TDMoIP, I will quote it.

BC: it is not OK to leave a gap like that even in an Informational.
We need the reference.
2006-10-09
06 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded by Brian Carpenter
2006-09-26
06 Mark Townsley Placed on agenda for telechat - 2006-10-12 by Mark Townsley
2006-09-26
06 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2006-09-26
06 Mark Townsley Ballot has been issued by Mark Townsley
2006-09-26
06 Mark Townsley Created "Approve" ballot
2006-09-15
06 Yoshiko Fong IANA Last Call Comments:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2006-09-04
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-08-21
06 Amy Vezza Last call sent
2006-08-21
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-08-21
06 Mark Townsley Last Call was requested by Mark Townsley
2006-08-21
06 Mark Townsley State Changes to Last Call Requested from Publication Requested by Mark Townsley
2006-08-21
06 (System) Ballot writeup text was added
2006-08-21
06 (System) Last call text was added
2006-08-21
06 (System) Ballot approval text was added
2006-07-06
06 Dinara Suleymanova
PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready …
PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

Yes

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

This document has been fully reviewed by the PWE3 WG.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

We have no concerns.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

We have no 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 is firm consensus for the design described in this document.
This document also aligns with the work of ITU SG13 Y.1453

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director.

No

1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes
The nits checker says no nits found, but the experimental section says
that there are four unused references and four references used that
are not included in the references section. Since the latter are all RFCs
this will not prevent the reviewer from understanding the document.
I therefore request that we start the formal review process and
fix this at the next iteration, or by note to the editor.

1.h) Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

Yes, it is correctly split into normative and informative references.
All normative references are either RFCs, or in the RFC-Editor
queue.


1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

This draft extends the work described in RFC4553 by describing
structure-aware methods of encapsulating Time Division Multiplexed
(TDM) signals as pseudo-wires over packet-switching networks (PSN).

The use of a structure-aware method of emulating TDM circuits make it
possible to safeguard TDM structure during transport over the PSN, thus
making possible to effectively withstand network degradations such as
packet loss events. TDM signaling also becomes visible, facilitating
mechanisms that maintain or exploit this. Finally, by taking advantage
of TDM signaling and/or voice activity detection, structure-aware TDM
transport makes bandwidth conservation possible.

Two structure-aware methods described in this draft. One uses a
structure-indication mechanism which is derived from the mechanism used
in ATM AAL1, and is best used when the channel allocation is static. The
other uses a structure-reassembly mechanism based on the mechanism used
in ATM AAL2, and may be used to conserve bandwidth when the channel
allocation is dynamic.

The methods described in this draft have been widely implemented,
and in particular are compatible with methods described in ITU-T
Recommendations Y.1413, Y.1414, Y.1452 and Y.1453.


* Working Group Summary

Although the Working Group was able to reach consensus on the
unstructured TDM emulation method (SAToP/RFC4553), it could
not reach consensus on the best method of emulating a structured
service. The PWE3 WG therefore decided to pursue two methods as
informational RFCs(draft-ietf-pwe3-cesopsn-07.txt and
draft-ietf-pwe3-tdmoip-05.txt) and to gain operational experience
with the technology before recommending a standards track approach.

* Protocol Quality

There are many implementations of this protocol, and it is
in operational service.
2006-07-06
06 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-06-22
05 (System) New version available: draft-ietf-pwe3-tdmoip-05.txt
2005-09-21
04 (System) New version available: draft-ietf-pwe3-tdmoip-04.txt
2005-02-17
03 (System) New version available: draft-ietf-pwe3-tdmoip-03.txt
2004-07-22
02 (System) New version available: draft-ietf-pwe3-tdmoip-02.txt
2004-07-22
(System) Posted related IPR disclosure: RAD Data Communications statement about IPR claimed in draft-ietf-pwe3-tdmoip-02
2004-06-02
01 (System) New version available: draft-ietf-pwe3-tdmoip-01.txt
2004-02-13
00 (System) New version available: draft-ietf-pwe3-tdmoip-00.txt