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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 25 Jul 2005 12:37:44 -0500

Hi Stewart,

Thanks a lot for your comments and suggestions.

>     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 nibble not
> SB> the control word.

Right, we should clarify that we have (typically) 2 MPLS labels and a PW
Control Octet.
 
>     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?

OK, we can reference the PW architecture
http://ietf.org/rfc/rfc3985.txt.

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

OK, we'll clarify in next revision.
 
>     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.

OK, we can reference [ECMP-AVOID] and [PW-CNTL-WORD] here as well in in
Section 4.2.
 
>     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?

OK, we can remove Figure 4 and just reference [PW-SIG].

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

The MNBA language suggested by Colin Perkins.  If the these values are
to be assigned in the future, then we need to specify a registry, which
we're not doing at the moment.
 
>     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 
> SB> earlier since it is a design choice.

OK, as above.

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

We should actually clarify the second sentence to say that:
"As discussed in Section 4.1, interface parameter sub-TLV type values
*need to be* specified in [IANA] for both the network control protocol
for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]."

[IANA]
http://ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.txt
does not now specify sub-TLV type values for the network control
protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472].

Thanks,
Regards,
Jerry 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Jul 2005 20:08:02 +0100

> we're not doing at the moment.

Yes, but you could imagine that some new requirement might come along
say sctp or dccp, and the language here will cause some argument.

Setting up the registry, is not difficult, and no one is going to
argue against Expert Review as the allocation policy in this case :)

> protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472].

OK - I saw a bunch of your values in there, and did not notice that
you needed more. It's likely that there will be another spin of
IANA when we resolve the allocation policy, so you should give Luca
the list to put in next time he does an update.

- Stewart