[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] RE: draft-ash-avt-hc-over-mpls-protocol-01.txt
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
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt