The MPLS WG Archive

[Magnus Westerlund <magnus.westerlund@ericsson.com>]

Hi Jerry,

Sorry for the delay in responding. Also I would still like to hear some 
response from the header compression people about the SCID issues.

In regards to rechartering I will send out a message to AVT with a 
proposed new charter for the WG members to comment on.

See comments inline.

Ash, Gerald R (Jerry), ALABS wrote:
>>
>>I would also like to point out that the Header Compression mechanism 
>>needs a return path from the decompressor mechanism. However the draft
> 
> 
>>does not seem to discuss this issue at all. Or is a MPLS label path 
>>automatically reversible?
> 
> 
> Jerry>> It is the CONTEXT_STATE packets that travel on the reverse path,
> as stated in the ID.  Here is the relevant passage in the ID:
> 
> "4. Compressed packets and header compression control packets
> (FULL_HEADER and CONTEXT_STATE packets) are routed on a separate LSP,
> set up by RSVP-TE, from non-compressed packets; FULL-HEADER packets are
> routed on the same R1/HC --> R4/HD LSP as the R1/HC to R4/HD compressed
> packets for the ECRTP flow; CONTEXT-STATE packets are routed on the same
> R4/HD --> R1/HC LSP as the R4/HD to R1/HC compressed packets for the 
> ECRTP flow.
> 5. compressed packets, FULL_HEADER packets, and CONTEXT_STATE packets
> are routed with MPLS labels.
> 6. R4/HD uses the incoming MPLS label and the SCID to locate the proper
> decompression context."
> 
> I think this is quite clear.
> 

No, it is not clear. This text seems more a statement of intention, than 
an actual solution. This is important part of the solution and effects 
the signalling and multiplexing mechanism. Can I assume that the same 
need to be able to multiplex multiple peers onto the same LSP exist also 
in the return path?

> 
>>It would be desirable if the MPLS people could consider if there exist
> 
> 
>>other ways of providing for the standard assumption on link layers
> 
> that 
> 
>>header compression has? For these assumption please see chapter 2 of
> 
> RFC 
> 
>>2508, section 4.1 of RFC 3095, and RFC 3409.
>>
>>For example, what would be the effects of requiring unique labels 
>>between ingress and egress and for the reverse path?
>>
>>What effects would it have to put the multiplexing point in the layer 
>>two extension?
> 
> 
> Jerry>> FYI, the proposed protocol extensions in the current draft are
> much the same as originally proposed by George Swallow (almost 5 years
> ago) to the MPLS WG for the 'Simple Header Compression' protocol
> http://www.watersprings.org/pub/id/draft-swallow-mpls-simple-hdr-compres
> s-00.txt.
> 

Okay, but you haven't answered my question. What would be the effect of 
putting the multiplexing that you propose using a split SCID space into 
the layer 2 extension?

> 
>>I would also like to see the draft be more header compression agnostic
> 
> 
>>as has been agreed on in the requirements phase. There is no problem 
>>with using ECRTP as an example how one realize the solution, however
> 
> the 
> 
>>necessary hooks and signalling must be in place for any header 
>>compression mechanism.
> 
> 
> Jerry>> It isn't obvious how to make this 'header compression agnostic'
> for 'any header compression mechanism', given the differences in HC
> protocol specifics, etc.  Also, it's not clear whether that would really
> buy a lot:  ROHC is the only other proposed protocol to be accommodated
> within HC over MPLS, and one more protocol extensions draft (perhaps
> taken on within the ROHC WG) seems like a reasonable approach.
> 
> 

To my understanding this solution consists of three parts.

1. Setup signalling
2. MPLS transport and multiplexing of header compression messages
3. Any potential extensions or adaptation to make the header compression 
work over the MPLS generated properties.

To my understanding the setup signalling must be generic and allow the 
setup of any header compression mechanism. So this part in my view needs 
to be HC mechanism agnostic.

The MPLS transport of compressed messages may not be agnostic but are 
probably similar.

If a header compression mechanism needs special extension or 
clarifications, like ROHC over re-ordering channels, fine. However we 
must ensure that the common requirements that the available HC 
mechanisms put, is supported by the MPLS HC solution.


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls