The IESG has approved the following document: - 'Protocol Extensions for Header Compression over MPLS ' <draft-ietf-avt-hc-over-mpls-protocol-08.txt> as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls-protocol-08.txt Technical Summary This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance very much as it would over a single point-to-point link. Working Group Summary This draft has been in development for several years, with the initial proposal being refined significantly in the course of the discussion, to provide a solid framework for header compression over MPLS pseudo-wires. Protocol Quality This draft is a product of the AVT working group, with input from MPLS, ROHC and PWE3. Extensive working group last call comments were provided by Kristofer Sandlund and Eric Gray. PROTO write-up by Colin Perkins. Note to RFC Editor 1. Section 1, 1st paragraph, line 11: OLD: and robust header compression (ROHC) [RFC3095], and also to increase NEW: and robust header compression (ROHC) [RFC3095, RFC3095bis], and also to increase 2. Section 2, 1st line above page break for Page 3: OLD: [RFC3095]), compressed RTP (cRTP, [RFC2508]), enhanced cRTP (ECRTP, NEW: [RFC3095, RFC3095bis]), compressed RTP (cRTP, [RFC2508]), enhanced cRTP (ECRTP, 3. Section 2, 2nd line above Section 3: OLD: In [RFC3095]. NEW: in [RFC3095, RFC3095bis]. 4. Section 2, definition of compressed Real Time Protocol (cRTP), 1st line: OLD: compressed Real Time Protocol (cRTP): a particular HC protocol NEW: compressed Real-time Transport Protocol (cRTP): a particular HC protocol 5. Section 2, definition of Enhanced Compressed Real Time Protocol (ECRTP), 1st line: OLD: Enhanced Compressed Real Time Protocol (ECRTP): a particular HC NEW: Enhanced Compressed Real-time Transport Protocol (ECRTP): a particular HC 6. Section 2, definition of Label Switching Router (LSR): OLD: Label Switching Router (LSR): an MPLS node which is capable of forwarding native L3 packets label stack an ordered set of labels NEW (these definitions need to be separated as follows and placed alphabetically in the list): Label Stack: an ordered set of labels Label Switching Router (LSR): an MPLS node that is capable of forwarding native L3 packets 7. Section 2: definition of Robust Header Compression (ROHC): OLD: Robust Header Compression (ROHC): a particular HC protocol described In [RFC3095]. NEW: Robust Header Compression (ROHC): a particular HC protocol consisting of a framework [RFC3095bis] and a number of profiles for different protocols, e.g. for RTP, UDP, ESP [RFC3095] and IP [RFC3843]. 8. Section 3, 2nd line above Figure 1: OLD: document may operate on TCP or IPSEC Encapsulating Security Protocol NEW: document may operate on TCP or IPsec Encapsulating Security Protocol 9. Section 4.1, first Table, line 1: OLD: 0x001A ROHC Transport Header-compressed Packets [RFC3095] NEW: 0x001A ROHC Transport Header-compressed Packets [RFC3095bis] 10. Section 4.2.3, 2nd paragraph, last sentence: OLD: These sub-options do not occur together. NEW: These sub-options MUST NOT occur together, if they do (e.g., if misconfigured) a decompressor MUST reject this option and send an explicit error message to the compressor [RFC3544]. 11. Section 4.2.5, sub-heading "MRRU", second line: OLD: reconstructed reception unit (see [RFC3095], Section 5.1.1). NEW: reconstructed reception unit (see [RFC3095bis], Section 5.1.2). 12. Section 4.3, next to last paragraph, 1st line: OLD: Note that ROHC [RFC3095] provides its own packet type within the NEW: Note that ROHC [RFC3095, RFC3095bis] provides its own packet type within the 13. Section 6, last line: OLD: RFC2508, RFC3095, RFC3545] all apply to this document as well. NEW: RFC2508, RFC3095, RFC3095bis, RFC3545] all apply to this document as well. 14. Section 8, 3rd line: OLD: 0x001A ROHC Transport Header-compressed Packets [RFC3095] NEW: 0x001A ROHC Transport Header-compressed Packets [RFC3095bis] 15. Section 9, next to last paragraph, 1st line: OLD: All the HC schemes used here are built so that if an ucompressible NEW: All the HC schemes used here are built so that if an uncompressible 16. Section 10, add the Informative Reference: [RFC3095bis] Jonsson, L-E., et al., "The RObust Header Compression (ROHC) Framework", work in progress. 17. all page breaks and references where "et. al." appears: OLD: et. al. NEW: et al. In section 4.2.3 replace OLD These sub-options do not occur together. NEW These sub-options MUST NOT occur together, if they do (e.g., if misconfigured) a decompressor MUST reject this option and send an explicit error message to the compressor [RFC3544]. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
