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