Subject: [rohc] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-00.txt

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 9 Jun 2005 12:34:00 +0200

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

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc