The MPLS WG Archive

["Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>]

Lars-Erik,
Magnus,

Thank you for your comments on "Protocol Extensions for ECRTP over MPLS"
http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-0
2.txt.

Please see responses below.

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').


Thanks,
Jerry

> I've now looked into the MPLS-HC solution draft as well as the
> mail exchanges between Magnus and Jerry. The problems I see with 
> the draft are very similar to those pointed out by Magnus. However,
> in an attempt to avoid getting too influenced by Magnus comments
> I will make my points purely based on my own reflections from the
> draft, and then from that refer to the discussion between Magnus
> and Jerry.
> 
> Overall document structure and purpose
> --------------------------------------
> On a high level, I think this MPLS-HC document should be about
> three things:
> 1) Negotiation of use, i.e. setup signaling
> 2) Encapsulation, i.e. how to send HC-packets over MPLS
> 3) Operation, i.e. considerations for the actual compression 
> scheme(s), e.g. how to implement the scheme(s) to be able to 
> handle reordering
> 
> 1-2 are addressed in the draft, while 3) is not, although it is
> essential as an ordinary implementation of the existing HC schemes
> would e.g. not necessarily work well enough in case of reordering.

I have no trouble with including discussion of #3 'operation'.
 
> I also strongly believe this MPLS-HC mapping solution should cover
> the currently available HC schemes, IP-HC, CRTP, ECRTP, and ROHC.
> I would not say we have to make it totally generic for *any* HC
> scheme, as I do not think we can cover up for future solutions. 
> RFC 3544 (i.e. RFC 2509bis), which provides 1) and 2) for IP-HC,
> CRTP, and ECRTP, as well as RFC 3409, which do the same for ROHC,
> could be used as a basis for this work. The similarities in how to
> solve 1), 2), and 3) for existing HC schemes should be dominating
> rather than the differences.

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.  I wouldn't think there is a large demand for
IPHC over 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?
 
> Context multiplexing within an LSP, why signaling?
> ---------------------------------------------------
> The second main concern I have is the same one as Magnus expressed,
> about the multiplexing, which seems to require signaling that I
> can not see the point of. As I know nothing about the details
> of MPLS, my question from reading the draft was simply why there
> would have to be any signaling for picking a CID value, existing
> HC schemes assume the compressor does this without any signaling.
> The draft just talks about "...to signal the SCIDs...", without
> explaining the meaning of this.
> 
> I do not exactly understand the underlying MPLS problem that Magnus
> talked about that might be the motivation for having to do CID tricks,
> but I agree with his concerns about this approach, which seems to
> require signaling for each new packet stream, and also contradicts
> the way existing HC schemes handle CID assignment. In any case, the
> draft should explain better the motivations behind solutions like
> this.

The issue is that MPLS labels may not be received at all at the header
decompressor (HD), or, if received, do not uniquely identify the source
of the compressed packets at the header compressor (HCO).  Therefore a
CID is used to uniquely identify the flow.  In order to avoid
duplication of CIDs at the HD, say from 2 HCs, HC-a and HC-b sending
compressed packets to the HD, it is necessary to signal from HCO to HD
to obtain unique CIDs allocated by the HD.  It is not acceptable to have
any chance of using the same CID for different flows occurring at the
same time.

> 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.  For example, RFC 3544
http://ietf.org/rfc/rfc3544.txt?number=3544 'IPHC over PPP', makes no
mention of negotiating parameters across tunnels, it is oriented toward
negotiating over a single PPP link (per the title of the RFC).  RFC 3544
uses RFC 1332 http://ietf.org/rfc/rfc1332.txt?number=1332 'PPP IP
Control Protocol (IPCP)' to signal/negotiate the HC parameters.  For
example, as specified in Section 2.3 of RFC 3544, the following ECRTP
parameter negotiation object is sent from header compressor (HCO) to
header decompressor (HD) over a PPP link using the IPCP specified in RFC
1332:

<begin>
2.3.  Enhanced RTP-Compression Suboption

   To use the enhanced RTP header compression defined in [RFC3545], a
   new sub-option 2 is added.  Sub-option 2 is negotiated instead of,
   not in addition to, sub-option 1.

   Description

      Enable use of Protocol Identifiers COMPRESSED_RTP and
      CONTEXT_STATE as specified in [RFC2508].  In addition, enable use
      of [RFC3545] compliant compression including the use of Protocol
      Identifier COMPRESSED_UDP with additional flags and use of the C
      flag with the FULL_HEADER Protocol Identifier to indicate use of
      HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets.

          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Type      |    Length     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type
         2

      Length
         2
<end>

For the HC over MPLS application, the above object would have to be sent
between HCO and HD over an MPLS LSP.  Perhaps this needs to be
identified as one of the packet types (see below).  In regard to the
operation of HC schemes over tunnels, RFC 2507 (IPHC)
http://ietf.org/rfc/rfc2507.txt?number=2507 does refer to operation over
IP tunnels in Section 4.1.  RFC 3095 (ROHC)
http://ietf.org/rfc/rfc3095.txt?number=3095 refers to operation over GRE
tunnels in Section 5.8.4.4.  It would be useful to know how these HC
schemes can already be made to work over IP and GRE tunnels, that is not
explained in RFC 2507 or RFC 3095.  That information would help to
explain how to 'negotiate HC scheme parameters' over MPLS tunnels.
 
> On the CID handling question, I also noticed the text about how to
> free up CID. I am not sure what the purpose of that is, but this also
> represents a deviation from how existing HC schemes are defined.
> Looking at packets not belonging to the flow (e.g. SIP messages)
> also seems like a not very desirable approach, in my mind.

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.
B. how to free up CIDs at the HCO when a flow has ended.

These issues are *not* addressed in *any* of the HC RFCs: IPHC (RFC
2507), CRTP (RFC 2508), ECRTP (RFC 3545), and ROHC (RFC 3095) are all
silent on how CIDs are selected, kept unique, and freed up.  So it is
unclear how to 'extend' existing HC schemes where the HCO selects the
CID when we don't have any documentation on what these existing schemes
are.

However, in looking at RFC 3550 (RTP)
http://ietf.org/rfc/rfc3550.txt?number=3550, it does discuss the issue
of assigning and freeing up the SSRC (synchronization source) ID, which
is kind of analogous to CID in the HC schemes.  An SSRC needs to be
assigned to an RTP flow by the RTP source on initiation of the flow, and
freed up when the flow ends.  Perhaps CRTP and ECRTP implementations use
the SSRC assignments to determine the CID assignments (only a guess)?
It would be good to know how the SSRCs are uniquely assigned and
removed, and how that might be applied to CID assignment and removal.  

Appendix A.6 of RFC 3550 gives an algorithm (and C code) to generate
random SSRC values, although of course there is non-zero probability of
having duplicate SSRC values at the receiver.  Sections 8 and 8.2 of RFC
3550 discuss the issues of probability of SSRC collision (duplication)
and collision resolution, although the words on collision resolution in
Section 8.2 are a bit vague:

<begin>
If a receiver discovers that two other
sources are colliding, it MAY keep the packets from one and discard
the packets from the other when this can be detected by different
source transport addresses or CNAMEs.  The two sources are expected
to resolve the collision so that the situation doesn't last. 
<end>

So how to chose CIDs at the HCO to completely avoid duplication at the
HD is one issue.  In any case, I feel it is essential to have *zero*
chance of duplicating CIDs in the HD, since 2 VoIP conversations might
get mixed together if CIDs are duplicated!?  That's why we opted to use
the RSVP-TE signaling approach to have the CIDs uniquely assigned by the
HD.

Freeing up CIDs to avoid running out of CIDs is the other issue.

Section 6.2.1 of RFC 3550 (RTP) discusses freeing up SSRCs after an RTCP
'BYE' packet is received, which ends the RTP session.  Section 6.3.5
discusses how to free up SSRCs after a time-out period.  This might work
for RTP flows, but how to do it for IPHC?  

Perhaps the issue of freeing up CIDs isn't quite as difficult as
avoiding duplication at the HD, but the issue of not running out of CIDs
at the HCO is a concern (maybe 16 bits is sufficient to always avoid
that?).

> What creates a feedback channel?
> --------------------------------
> Is the LSP per definition bidirectional, or are LSP's always set up
> as pairs, one in each direction? If we talk about multiple LSP's,
> there must be an exact 1-1 mapping, or there must be a way to create
> that binding between them.

We propose the following additional text in the I-D to explain the
creation of the feedback MPLS LSP channel:

"In Figure 1, we assume an example VoIP flow set up from R1/HC --> R2
--> R3 --> R4/HD, where R1/HC is the ingress router where header
compression (HC) is performed, and R4/HD is the egress router where
header decompression (HD) is done, and in the reverse direction.  Each
router functions as an LSR and supports RSVP-TE signaling of LSPs.

Now we describe the following MPLS functions:
1. Associating the A-->B RTP flow with the B-->A RTP flow
2. Associating the A-->B LSP with the B-->A LSP
3. Signal the SCID for both the A-->B and B-->A RTP flows.
A summary of the ECRTP flow setup is as follows:

1. R1/HC sends an RSVP-TE PATH message to R4/HD, which includes a
SCID_Request object with a 2-byte ECRTP-Flow-ID.  The RSVP-TE PATH
message causes the intermediate LSRs R2 and R3 as well as R4 to install
state, insuring that the R1 --> R4 LSP will be set up by the RESV
message, which follows the prescribed path in the reverse direction.
For an IP network in general, the reverse path might not be same as the
forward path, but in the case of MPLS-TE, the state installed by the
RSVP PATH message determines the path of the LSP to be set up by the
RSVP RESV message.
2. R4/HD assigns a unique 2-byte SCID to the call and sends an RSVP-TE
RESV message to R1/HC that includes a Header_Compression_Reply object
with the ECRTP-Flow-ID and the assigned SCID.  This RSVP RESV message
traverses the path R4 --> R3 --> R2 --> R1, creating the R1 --> R4 LSP
that follows that path.   R1/HD uses this LSP to send CONTEXT_STATE
packets to R4/HC and R1/HC uses this LSP to send compressed packets to
R4/HD.
3. R4/HC sends an RSVP-TE PATH message to R1/HD, which includes a
SCID_Request object with a 2-byte ECRTP-Flow-ID.  The RSVP-TE PATH
message causes the intermediate LSRs R3 and R2 as well as R1 to install
state, insuring that the R4 --> R1 LSP will be set up by the RESV
message, which follows the prescribed path in the reverse direction.  
4. R1/HD assigns a unique 2-byte SCID to the call and sends an RSVP-TE
RESV message to R1/HC that includes a Header_Compression_Reply object
with the ECRTP-Flow-ID and the assigned SCID.  This RSVP RESV message
traverses the path R1 --> R2 --> R3 --> R4, creating the R4 --> R1 LSP
that follows that path.   R4/HD uses this LSP to send CONTEXT_STATE
packets to R1/HC and R4/HC uses this LSP to send compressed packets to
R1/HC.
5. R1/HC sets the SCID in compressed packets and FULL_HEADER packets.
6. 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; for example, 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.
7. Compressed packets, FULL_HEADER packets, and CONTEXT_STATE packets
are routed with MPLS labels.
8. R4/HD uses the incoming MPLS label and the SCID to locate the proper
decompression context.
9.  If needed to resync, R4/HD sends a CONTEXT_STATE packet to R1/HC
with SCID set; R1/HC resends FULL_HEADER packet with SCID set to R4/HD,
etc.
10. R4/HD frees up the SCID when the ECRTP flow disconnects (e.g., as
indicated by RTP BYE message and RSVP-TE/PATH-TEAR messages), or by
refreshing the PATH state."

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

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.  Also, this was an issue/concern
raised by Loa Anderson when the HC over MPLS I-Ds were reviewed on the
MPLS list a few months ago.  Please let me know what you think of this
proposal.

> HC object formats
> -----------------
> This section was very confusing to me. First, the text talks about
> intermediates that do not understand HC and could drop the object.
> My question is, should not the solution be transparent to 
> intermediates,
> i.e. compression should be possible between ingress and egress without
> any knowledge in the notes in between? Why should it at all concern
> intermediates?

This is some standard discussion of how MPLS objects are treated at
intermediates, however, some additional explanation/clarification can be
added as you suggest.
 
> Further, I have a hard time commenting on the content as the fields
> in these objects are not described. There should be explanations
> after the figures.

Agreed.
 
> Operations
> ----------
> For the operations part, the draft currently says nothing, while we
> know there are at least concerns related to reordering. The ROHC over
> reordering draft can be a useful source for information in that area,
> as well as the ECRTP evaluation I made the list aware of 
> earlier today.
>
http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-01.t
xt
> http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf

I agree that relevant 'operations' guidance should be included.

> Summary
> -------
> I thus suggest that the overall purpose of this document (to be
adopted
> as a WG document) should be to create a HC mapping for MPLS, covering
> the HC schemes we currently have, similar to RFC 3544 and 3409. It
> should address negotiation (setup), encapsulation, and potential
issues
> with operation of each HC scheme. 
> 
> I'll do my best to support this work from an HC perspective.

OK, good.  Please see the above comments, questions, and requests for
input/clarification regarding your comments and suggestions.  Your input
and other MPLS/header compression SME input to specifically answer these
questions would be very much appreciated.

Thanks,
Jerry

> 
> Cheers,
> /L-E
> 
> 
> > -----Original Message-----
> > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]
> > Sent: den 22 december 2004 22:30
> > To: IETF AVT WG; rohc@ietf.org; mpls@ietf.org
> > Subject: [AVT] [mpls] Comments
> > ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt
> > 
> > Hi,
> > 
> > Sorry for the crossposting, however this is something that I think
needs
> > to be generally discussed between all 3 WGs. To me it looks like the
> > proposed solution for VoIP header compression across an MPLS network
> > contains a problematic demultiplexing mechanism. I don't think
people 
> > has realized the issues with the proposed mechanism due to lack of 
> > communication between the header compression and MPLS folks. 
> >
> > If it is my lack of knowledge please educate me, and the others. I 
> > would request that people providing input in this discussion is
> > overly explaining as education seems necessary.
> > 
> > The current draft is available at
> >
http://ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-0
2.txt:
> > 
> > The header compression mechanisms such as CRTP and ROHC to my 
> > understanding assumes that they have a lower link layer that
> > carries their compressed messages between compressor and 
> > decompressor. This is due to that they are intended to be
> > used with only a single link between the compressor and 
> > decompressor. In the case of CRTP, it also assumes that the 
> > link-layer can also provide the with identification of the 
> > packet types, while ROHC makes this identification internally.
> > 
> > The MPLS network uses one or more labels in the transport between 
> > ingress and egress from the MPLS network. Due to the possible 
> > relabeling in the middle of the network, it can't be generally
> > assumed that packets arriving with the same label comes from the
> > same ingress point. This makes the label not sufficient to 
> > identify the ingress for the egress, thus not making labels equal
> > to a link.
> > 
> > The proposed solution has thought of the above MPLS problem 
> > and proposes that one uses the setup signaling to allow the 
> > decompressor point to select which parts of its context
> > identifier (SCID) space that belongs to different ingress points
> > that arrives over the same label. However my understanding is
> > that this definitely not without problems for the header
> > compression mechanisms. I would like the header compression guy 
> > to clarify what problems that would arise from such a solution. One 
> > thing I definitely can see would be an issue, the proposed change
> > would prevent MPLS HC to use any standard implementation of the HC 
> > mechanism used.
> > 
> > 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?
> > 
> > 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?
> > 
> > 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 signaling must be in
> > place for any header compression mechanism.
> > 
> > So lets get the discussion going and hope that something good
> > results.
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > AVT Chair

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