The MPLS WG Archive

["Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>]

Jerry,

I've provided further comments below. Since I fully agree
with Magnus comment 1. on how to map existing HC solutions
to MPLS, i.e. to address the right problem here, I will
not repeat that discussion and therefore I do not address
the CID negotiation and allocation part. However, I'll
comment on a number of things that I find strange, unclear
or incorrect.


> Hopefully we will get MPLS and header compression SMEs to 
> make comments and suggestions on the rather complex issues
> you have raised (e.g., signal the CIDs 'at layer 2',
> negotiate the HC parameters 'at layer 2').

I do not think I have suggested to signal CIDs at layer 2,
but I have pointed out that all existing HC schemes let the
layer 2 protocol negotiate the CID-space to be used, and 
CIDs are then allocated by the compressor (within that space).


> Both Lars-Erik and Magnus are pushing for a solution to HC
> over MPLS that includes all existing HC schemes: IPHC (RFC 2507),
> CRTP (RFC 2508), ECRTP (RFC 3545), and ROHC (RFC 3095). 
> Recall that the original AVT charter item was limited to
> ECRTP.  Probably it is OK to generalize to CRTP, ECRTP, and
> ROHC, given the similarities in these protocols.  However,
> I'm concerned about the possible morass of issues this may lead
> to regarding each of the schemes, especially wrt IPHC (RFC 
> 2507), which addresses HC for TCP, etc.  

Considering that IPHC is the basis for CRTP, and thus also
eCRTP, I just do not see a reason to exclude IPHC if the AVT
WG decides to develop an HC mapping for MPLS.


> > By the way, could we please avoid the terminology 
> > "control/data plane".
> 
> This is common terminology, I don't know what is the issue
> with using this terminology?

I know this terminology is commonly used within the telecom
industry, but I do not consider it common IETF terminology.
So, if you want to use that terminology here, in the context
of header compression, you would have to define what it means,
as its telco meaning does not really makes clear sense here.


> It is not acceptable to have any chance of using the same CID
> for different flows occurring at the same time.

Here I fully agree with you, but existing HC schemes are designed
based on the assumption that they operate on a dedicated link
where this can not happen, and as Magnus has pointed out, the
problem we should address here is how to create that point2point
link over MPLS.


> > For the negotiation & encapsulation I would strongly recommend using
> > RFC 3544 and RFC 3409 as a basis, and clearly highlight potential 
> > deviations from the solutions used in these RFC's, that would help
> > to get more constructive involvement from the HC folks in this work.
> 
> Regarding 'negotiating HC scheme parameters', it is probably 
> valid that we should address how the HC scheme parameters are
> negotiated across an MPLS LSP.  However, the current RFCs don't
> specify how this can be done across a (IP, GRE, or MPLS) tunnel. 

No, of course they do not, as they are for HC over PPP. However, they
do handle all parameters that require negotiation for the various
schemes, so you know what a mapping for the same schemes would require
also in the MPLS case. Therefore, I think these RFC's have a useful
base to be used for the MPLS HC mapping work.


> There are two issues of concern on the CID handing question:  
> A. how to avoid duplication of CIDs at the HD for different flows.  If
> the HCO assigns the CIDs rather than the HD (as currently proposed in
> the I-D, through RSVP-TE signaling), there is possible duplication of
> CIDs at the HD for different flows.

And my view of that problem is that the solution should make sure such
duplication can not happen, by making sure one HD only get packets from
one single peer HCO.


> B. how to free up CIDs at the HCO when a flow has ended.

Don't, but let the compressor control when/how to re-use CIDs when
it gets out of CID-space. This is how existing HC schemes work.

 
> > ECRTP packet type identification
> > --------------------------------
> > Inconsistency, first paragraph of 2.2 talks about a 4-bit 
> > packet type, while the second paragraph says a one-octet
> > PT ID is used. In the figure, I wonder what the first octet
> > of zeros is, not really explained. 
> > "Defined by PPP Data Link Layer Protocol" means?
> 
> You are correct about the inconsistency, which needs to be corrected.
> 
> Furthermore, perhaps the 2 byte packet type identifier we now 
> specify in Section 2.2 of
> http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-
> protocol-0 2.txt could be reduced to 1 byte, as follows:
> 
> <begin>
>            0 1 2 3 4 5 6 7 8
>            +-+-+-+-+-+-+-+-+
>            |0 0 0 0|Pkt Typ|
>            +-+-+-+-+-+-+-+-+
> where:
> 
>         SCID_Packet_Type designation:
>         0000 (first nibble)
> 
>         "Packet Type" encoding:
>         0: Reserved
>         1: FULL_HEADER
>         2: COMPRESSED_TCP
>         3: COMPRESSED_TCP_NODELTA
>         4: COMPRESSED_NON_TCP
>         5: COMPRESSED_RTP_8
>         6: COMPRESSED_RTP_16
>         7: COMPRESSED_UDP_8
>         8: COMPRESSED_UDP_16
>         9: CONTEXT_STATE
>         10: ROHC
>         11 - 15: RESERVED
> <end> 

If you handle the choice of HC scheme in negotiation, you could
(for ROHC) save this extra octet for type identification. Type
identification is more efficiently handled within the compressed
header itself, as ROHC do.

> We need to add an ROHC packet type, as pointed out in Section 
> 2.6 of RFC 3409 http://ietf.org/rfc/rfc3409.txt?number=3409.
> It is also pointed out that ROHC further identifies the packet
> type within its header.  I don't feel we need to reserve 246
> additional packet types with a 1-byte field, which seems like
> overkill.  

If you still add padding, I would rather see a 1-octet field. 


Cheers,
/L-E

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