[AVT] Protocol Action: 'Protocol Extensions for Header Compression over MPLS' to Proposed Standard

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

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