[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] RE: [rohc] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt
Jerry and others,
First of all, I must say you've done a great job with this update. The
technical solution is starting to get in shape, and so also the draft
itself. I just have a few issues that I believe should be given some
additional attention, and I'll start with the least technical one:
* References
- There is one incorrect reference to RFC 3409, which I think has
not much to do with this document. The correct document to refer
to is RFC 3241, "Robust Header Compression (ROHC) over PPP".
- There is one invalid reference [IPCP], I guess it should be [RFC1332]
- As it is currently written, I believe [RFC3544] and [RFC3241]
would be normative for this document. I believe some other
references, e.g. some MPLS references, would also be normative.
- There are many informative references, go through them and make
sure they all are actually bringing any value as informative to
this document (I am not sure about the MPLS references). It might
also make sense to group them based on content (HD vs MPLS, etc),
that would make it easier for the reader.
* Separation of functionality
As previously discussed, I believe it would be useful to more
clearly separate negotiation/setup/signalling from encapsulation. As
it now stands, I am not sure I understand what purpose the separation
of chapter 2 and chapter 3 serves. Chapter 2 is about both setup and
encapsulation, while chapter 3 is about setup only.
* Requirements fulfilment
In chapter 1, it is said that the outlined solution fulfils the
requirements of [MPLS-HC-REQ]. I am not sure this listing is really
needed, neither do I think it is fully correct.
a) is true, that is a design decision for this document
b) is also true, ok, it is the whole purpose of the document
c) is not really achieved by this document, but depends on the
header compression scheme used, and especially on how that
scheme is implemented. This document can not guarantee anything
in this regard, but it provides what it can to make this possible.
What this document do indeed provide, is the mechanism to avoid
multiple compression/decompression cycles, but that is b) above.
d) "signal context identification", I do not know what is meant
with that, neither do I know what standard protocols are referred
to, is it the MPLS PW mechanisms that are meant, and/or the
HC-over-PPP specifications (for the latter, see also below).
e) this is implementation dependent on HC-protocol level, and it
is out of control of this specification, which is dependent on
the HC scheme implementation(s). Or do PW provide means for
in-order delivery?
Overall, I do not see the point of listing these things here. I
think it is sufficient to say that the solution(s) outlined in
this document have been designed and chosen to address the
goals and requirements of [MPLS-HC-REQ].
* "Flow Setup", end of chapter 2 introduction
- Is this really only about "setup"? It does not look so to me.
- I believe this can be generalized so that it is HC-scheme
independent, should not be hard to do.
- It is not clear whether 2) is mandatory or not, i.e. is it
mandatory to have a bidirectional connection?
* "Flow setup", last bullet, "Free up CID when flow terminates"
- How can one ever know that a flow has terminated? For UDP-based
"flows", there is no such thing. Also, why should one free
CIDs, I agree CIDs should be re-usable, but if memory is
allocated for a certain number of CIDs, that memory should
last as long as the HC instance(s) is(are) alive. It is the
compressor that may choose to re-use a CID. This has been
thoroughly discussed in the ROHC WG, captured in chapter 7
of <draft-ietf-rohc-rtp-impl-guide-11.txt>.
* Link layer packet type field
The requirement that link layers must provide packet type
identification for HC packets does not apply to ROHC. Therefore
I believe it is an improper design to require the extra
multiplexing byte (Pkt Typ field) for all schemes. There is
a negotiation of HC scheme done for the "channel", so why not
say that for schemes that can not identify their own packet
types, the extra byte is needed, as described. Or actually
negotiate whether to have this byte, independent of HC scheme
(although some require it).
* I think it makes sense to re-use the principles of RFC 3544 and
RFC 3241, but I also think this document will actually have to
define more specifically how the negotiation is done (with
similar principles as in 3544 and 3241). Both RFC 3544 and RFC
3241 are written as plug-ins to the PPP control protocol IPCP,
so just referring to them here where there is no PPP or IPCP
does not convince me about the completeness of the solution.
Rgds,
/L-E
> -----Original Message-----
> From: rohc-bounces at ietf.org [mailto:rohc-bounces at ietf.org]On Behalf Of
> Ash, Gerald R (Jerry), ALABS
> Sent: den 22 april 2005 00:06
> To: rohc at ietf.org
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: [rohc] RE: I-D
> ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt
>
>
> Hi All,
>
> Please review and comment on the (significantly) updated
> draft "Protocol
> Extensions for Header Compression over MPLS"
> (http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpl
> s-protocol
> -00.txt).
>
> Here is a brief background and overview/explanation of the updates:
>
> Work on requirements for header compression over MPLS
> (http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-mpls-re
> qs-03.txt)
> is complete, and work on protocol extensions for header
> compression over
> MPLS is underway (previous draft at
> http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-
> protocol-0
> 2.txt). Chartering of the protocol work in the AVT working group has
> been submitted for approval with the following milestone:
>
> Dec 05: Submit any extensions for RTP HC on MPLS networks for Proposed
> Standard
>
> There has been considerable discussion on the previous protocol
> extensions draft
> (http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls
> -protocol-
> 02.txt) in the last couple of months. I presented the update on the
> header compression over MPLS protocol extensions work at the
> AVT meeting
> at IETF-62; slides and minutes are available at
> https://datatracker.ietf.org/public/proceeding_interim.cgi?mee
> ting_num=6
> 2 (look under AVT for minutes and slides). The recent discussion and
> issues regarding the basic approach are summarized in the slides.
>
> Header compression experts in the AVT and ROHC working groups wish to
> re-use, and extend, the existing layer 2 approaches for assignment of
> context identification (CID) and header compression parameter
> negotiation. In a multipoint-to-point MPLS environment, one approach
> would be to have the various header compressors assign CIDs as they do
> now, with the possible need to resolve CID conflicts/collisions at the
> header decompressor. Some comments were made that current header
> compression methods do not have to resolve CID collisions, however the
> synchronization source (SSRC) assigned in RTP could need
> collision/conflict resolution.
>
> A second approach, suggested by Andy Malis and Loa Andersson,
> is to use
> pseudowires and/or targeted LDP to create 'point-to-point' sessions
> between header compressor and header decompressor, thereby
> avoiding any
> issue of CID collision. The disadvantage of this approach is that it
> requires an additional 4-byte label to be carried with each packet.
>
> The updated draft based on the second approach is available at
> http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls
> -protocol-
> 00.txt.
>
> Once again, please review and comment on the updated draft.
>
> Thanks,
> Jerry
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt