[AVT] draft-ash-avt-hc-over-mpls-protocol-01.txt

[Stewart Bryant <stbryant at cisco.com>]

   In the example scenario, header compression therefore takes place
   between R1 and R4, and the MPLS path transports
   data/compressed-header/MPLS-labels instead of
   data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet.

SB> You claim a size reduction but at this stage you have not
SB> said what the MPLS stack looks like. I assume that you have
SB> two labels, and as I recall you have just the 000 nible not
SB> the control word.

   The MPLS
   label stack and link-layer headers are not compressed.  Therefore HC
   over MPLS can significantly reduce the header overhead through
   compression mechanisms.

   MPLS is used to route HC packets over an MPLS LSP without
   compression/decompression cycles at each intermediate router.  MPLS
   pseudowires (PWs)
SB> perhaps a reference?

                                   8 octets              V
                                   +------+----------------------------+
                       MPLS Labels |header|                            |
                                   +------+----------------------------+
                                   \_________________ _________________/
                                                     V

SB> The above is technically two layers - the PW ident and the CE
SB> identifier. You may have other MPLS labels for example if you are
SB> going over a VPN.

   The PW control octet is used to identify the packet types for certain
   HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508],
   and ECRTP [RFC3545], as detailed in Section 4.2.

SB> You should call up <draft-ietf-mpls-ecmp-bcp-01.txt> and
SB> perhaps <draft-ietf-pwe3-cw-05.txt> to explain why your bytes
SB> start with zero.

   Note that ROHC
   [RFC3095] provides its own packet type within the protocol, and does
   not require use of the PW control octet.

SB> see above



4. Protocol Specifications


   In Figure 1 we assume an example data flow set up from R1/HC -->
   R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header
   Compression is performed, and R4/HD is the egress router where header
   Decompression is done.  Each router functions as an LSR and supports
   signaling of LSP/PWs.  A summary of the procedures is as follows:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sub-TLV Type  |    Length     |    Variable Length Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Variable Length Value                 |
   |                             "                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 4 - PW Interface Parameters Sub-TLV

SB> Do you need to copy this - wouldn't it be better to just reference
SB> the definitive copy in the PW control RFC - just in case any typos
SB> creep in?



   Figure 3 shows the HC over MPLS protocol stack.  The PW control octet
   is used to identify the packet types for certain HC schemes,
   including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and ECRTP
   [RFC3545], as shown in Figure 5:


                             0 1 2 3 4 5 6 7 8
                             +-+-+-+-+-+-+-+-+
                             |0 0 0 0|Pkt Typ|
                             +-+-+-+-+-+-+-+-+

                       Figure 5 - PW Control Octet

   where:

   "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-15: MUST NOT BE ASSIGNED

SB> re 10-15 - Why MNBA? Or do you mean reserved?


   As discussed in [ECMP-AVOID], since this MPLS payload type is not IP,
   the first nibble is set to 0000 to avoid being mistaken for IP.  This
   is also consistent with the proposed encoding of the PWE3 control
   word [PW-CNTL-WORD].

SB> OK, you say this here. I think that you should say it earlier since
SB> it is a design choice.




7. IANA Considerations

   As discussed in Section 4.1, new PW type values are assigned in
   [IANA] for HC over MPLS LSP/PWs.  As discussed in Section 4.1,
   interface parameter sub-TLV type values are specified in [IANA] for
   both the network control protocol for IPv4, IPCP [RFC1332] and the
   IPv6 NCP, IPV6CP [RFC2472].

SB> You say that all IANA actions are described
SB> in IANA and there are no additional IANA actions. Just to
SB> make it clear for the IANA reviewer.



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt