Document: draft-ietf-avt-hc-over-mpls-protocol-07 Reviewer: Spencer Dawkins Review Date: 2007-01-30 IETF LC End Date: 2007-02-07 Summary: This document is on the right track for publication as Proposed Standard. I had some questions (please see below), but the quality seemed very good (thanks for that). I'd like to see some work on my comments in 5.1, 5.2 (especially 5.2.1), and 5.3. I had some comments on clarity in section 6, but these were more-than-nits-but-not-problems. Comments: 1. Introduction Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC2547]) use label stacking, and in the simplest case of IPv4 the total packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. When IPv6 is used, the relative size of the header in comparison to the payload is even greater. The interest in header compression (HC) is to exploit the possibility of significantly reducing the overhead through various compression mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545] and robust header compression (ROHC) [RFC3095], and also to increase scalability of HC. MPLS is used to route HC packets over an MPLS label switched path (LSP) without compression/decompression cycles at each router. Such an HC over MPLS capability can increase bandwidth efficiency as well as the processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. Goals and requirements for HC over MPLS are discussed in [RFC4247]. The solution put forth in this document using MPLS pseudowire (PW) technology has been designed to address these goals and requirements. Spencer (Nit): I think the last sentence is actually "The solution using MPLS pseudowire (PW) technology put forth in this document has been designed to address these goals and requirements." (the solution wasn't actually put forth using MPLS PW technology :-) 2. Contributors Besides the editors listed in Section 12, the following people contributed to the document: Spencer (Nit): I like the use of this section, but it seems odd to have it so far from the acknowledgements section. I'm not sure if IESG has an agreed sense of taste for placement or not. Cullen? 3. Terminology PSN Tunnel Signaling: Used to set up, maintain, and tear down the underlying PSN tunnel Spencer (Nit): s/Used/A protocol used/ (all of the other definitions look like complete sentences, this one is a fragment) 5.1 MPLS Pseudowire Setup & Signaling This specification defines new PW type values to be carried within the FEC object to identify HC PWs for each HC scheme. The PW type is a 15-bit parameter assigned by IANA, as specified in the [RFC4446] registry, and MUST be used to indicate the HC scheme being used on the PW. The following PW type values have been set aside for assignment by IANA: 0x001A ROHC Transport Header-compressed Packets [RFC3095] 0x001B ECRTP Transport Header-compressed Packets [RFC3545] 0x001C IPHC Transport Header-compressed Packets [RFC2507] 0x001D cRTP Transport Header-compressed Packets [RFC2508] Spencer: "have been set aside for assignment by IANA", with RFC references, confused me badly here. I read this text as saying that these values were set aside IN [RFC3095], etc, which was wrong. Perhaps "IANA is requested to assign the following new PW type values:"? The PW control word enables distinguishing between various packets types (e.g., uncompressed, UDP compressed, RTP compressed, context-state, etc.). However, the PW control word indications are not unique across HC schemes, and therefore the PW type value allows the HC scheme to be identified. 5.2 Header Compression Scheme Setup, Negotiation, & Signaling Pseudowire Interface Parameter Sub-TLV type values are specified in [RFC4446]. Two code-points have been reserved, as follows: Parameter ID Length Description References 0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241 0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544 configuration Spencer: Again, something like "IANA is requested to assign these new code-points" would help me with what seems to be ambiguous text. 5.2.1 Configuration Option Format [RFC3544] Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters for their respective protocols. The format of the configuration Spencer (Nit): I understand what you're saying with "their respective protocols", but I don't think what you're saying, and what I'm hearing, is actually what these words mean. Perhaps "their respective controlled protocols"? That would be unambiguous. option is the same for both IPCP and IPV6CP. This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. Spencer: Is it obvious what the decompressor does if it sees this configuration option for ROHC PW types? It may be - I'm just asking. I'd have the same question elsewhere (in 5.2.2, for example), but will only ask it here. 5.2.3 Enhanced RTP-Compression Suboption [RFC3544] To use the enhanced RTP HC defined in [RFC3545], a new sub-option 2 is added. Sub-option 2 is negotiated instead of, not in addition to, sub-option 1. This suboption MUST be included Spencer: is it obvious what the decompressor does if it sees a compressor specifying sub-option 1 AND sub-option 2? for ECRTP PWs (0x001B) and MUST NOT be included for other PW types. MAX_HEADER NOTE: The four ROHC profiles defined in RFC 3095 do not provide for a MAX_HEADER parameter. The parameter MAX_HEADER defined by this document is therefore without consequence in these profiles. Other profiles (e.g., ones based on RFC 2507) can make use of the parameter by explicitly referencing it. Spencer: is there any statement you can make about the largest header that can be compressed in these profiles? Even if not, it might be good to say so explicitly - I don't know what "without consequence" says about what implementations may encounter in practice. 5.4 Packet Reordering Packet reordering for ROHC is discussed in [RFC4224], which is a useful source of information. In case of lossy links and other reasons for reordering, implementation adaptations are needed to allow all the schemes to be used in this case. Although CRTP is viewed as having risks for a number PW environments due to reordering Spencer (Nit): "a number of PW environments" ("of" is missing) and loss, it is still the protocol of choice in many cases. In these circumstances, it must be implemented and deployed with care. IPHC should use TCP_NODELTA, ECRTP should send absolute values, ROHC should be adapted as discussed in [RFC4224]. An evaluation and simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL]. Spencer (Probably a Nit): It wasn't obvious to me whether these recommendations are sufficient to "implement and deploy with care", or whether additional precautions must be taken. Even putting these recommendations in a numbered list immediately after "deployed with care" would be sufficient, if these recommendations are sufficient. 6. HC Pseudowire Setup Example The Label Mapping message sent from R4/HD to R1/HC would be almost identical to the one sent in the opposite direction, with the following exceptions Spencer (Nit): missing a colon here... As soon as either R1/HC or R4/HD had both transmitted and received Label Mapping Messages with the same PW Type and PW ID, it could Spencer: "it" is not entirely clear here. "It" usually refers to one thing (in my mind), and the subject of the sentence is two things ("either R1/HC or R4/HD"). Mumble. Would it help to say that each ROHC endpoint considers the PW established when it has seen both packets? consider the PW established. R1/HC could send ECRTP packets using the label it received in the Label Mapping Message from R4/HD, Lr4, and could identify received ECRTP packets by the label it had sent to R4/HD, Lr1. And vice versa. The following 3 RTP packets from this flow would be sent as Spencer: "following" is not entirely clear here. Suggest "next"? COMPRESSED_UDP_8, to establish the absolute and delta values of the IPv4 identifier and RTP timestamp fields. These packets would use the same ECRTP CID as the previous 3 FULL_HEADER packets. The MPLS and PW headers at the beginning of these packets would be formatted as follows: