[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt
> > * Separation of functionality
> >
> > As previously discussed, I believe it would be useful to more
> > clearly separate negotiation/setup/signaling 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.
>
> OK, perhaps we could map current Sections 2 and 3 into the following
> sub-sections:
>
> Section 2.1: link layer encapsulation type field (current
> Section 2.2)
> Section 2.2: PW and HC scheme negotiation/setup/signaling (current
> Sections 2.1 and 3)
> Section 3: procedures summary (from "In Figure 1 ..." in
> current Section 2)
Ok, I will try to elaborate more on what I am after here. As it is
right now, I can not get a grip on the overall solution here, which
directly relates to the last comment I had (see below).
What I would like to have as a structure could be something like:
1. Introduction
This section should include the header compression overview
now present in section 2.
2. Terminology
Here we put the 2119 keywords reference, as well as other
important keywords that are not generally known by the typical
audience.
3. Overview of Header Compression over MPLS
Here I would like to see a high level description of how HC
over MPLS is realized. i.e. explain that PW's are used to
create P2P links, which protocols are used on top of which,
what protocol(s) are used for negotiation, and which
encapsulation is used. Here are the normative reference
protocols introduced and referenced. It should be clear
from this section what protocol takes care of HC parameter
setup, i.e. how is HC scheme type negotiated, and how are
scheme-specific parameters negotiated. Is PPP/HDLC used over
the PW and HC then applied on top of that using the standard
ROHC/CRTP/eCRTP over PPP protocols, or is HC applied directly
over its own PW type, just re-using the principles of HC*-over-
PPP???
This section should present the big picture!
4. Protocol specifications
Here we would get the various details of the high level
principles outlined in 3.
4.1. Setup and negotiation
How to setup PW, how to configure/signal the use of HC over
PW (potentially including which HC-scheme to use, I would
prefer that solution), and how to signal HC-scheme parameters.
The last part would e.g. correspond to section 2 of RFC 3241.
4.2. Encapsulation
How to encapsulate compressed packets, e.g. with the type field
needed for non-ROHC schemes.
5. Procedure overview
This is in my opinion not actually *needed*, but could serve
as a useful summary, making use of what has been described in
section 3-4.
> > * 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).
>
> Dynamic negotiation of the multiplexing byte may require a
> bit more work and complexity than is desirable. Since the
> gateways need to be configured for each HC type anyway, we could
> follow this suggestion by saying that the extra byte will be
> needed for those HC schemes that can not identify their own
> packet type. That is, an extra byte will be added by default
> once a certain HC type is configured.
Sounds good, I think it makes sense to spell out the required
encapsulation format for each HC type. Using different PW-types
for different HC schemes sounds like a good idea, I think.
> > * 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.
>
> Are you suggesting that we provide a more detailed specification to
> extend the use of IPCP or similar scheme for HC parameter negotiation
> over MPLS?
You have to specify what protocols are actually used, and how they
fit together. Either you normatively use a protocol, or you just
model your own protocol on an existing one. For the former case, you
have to explain what is used and how it is glued together, in the
latter case you have to specify your own protocol in detail, referring
to existing protocols could serve as background information, but not
more than that.
I do not actually know what is missing before I get the big picture
of how the solution is envisioned, as I would like to see in chapter 3.
In the current draft, it is very unclear (at least to me) what
protocols are actually used for HC over MPLS, and which are only
referred to. As an example, one can not make use of 3241 if 1332 is
not available, which also requires 1661. Do we have PPP and IPCP here?
Cheers,
/L-E
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt