4247
INFORMATIONAL
Requirements for Header Compression over MPLS
Authors: J. Ash, B. Goode, J. Hand, R. Zhang
Date: November 2005
Area: rai
Working Group: avt
Stream: IETF
Abstract
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario. This memo provides information for the Internet community.
RFC 4247
INFORMATIONAL
Network Working Group J. Ash
Request for Comments: 4247 B. Goode
Category: Informational J. Hand
AT&T
R. Zhang
BT Infonet
November 2005
<span class="h1">Requirements for Header Compression over MPLS</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Voice over IP (VoIP) typically uses the encapsulation
voice/RTP/UDP/IP. When MPLS labels are added, this becomes
voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is
typically 48 bytes, while the voice payload is often no more than 30
bytes, for example. Header compression can significantly reduce the
overhead through various compression mechanisms, such as enhanced
compressed RTP (ECRTP) and robust header compression (ROHC). We
consider using MPLS to route compressed packets over an MPLS Label
Switched Path (LSP) without compression/decompression cycles at each
router. This approach can increase the bandwidth efficiency as well
as processing scalability of the maximum number of simultaneous flows
that use header compression at each router. In this document, we
give a problem statement, goals and requirements, and an example
scenario.
<span class="grey">Ash, et al. Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Problem Statement ...............................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Specification of Requirements ..............................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Goals and Requirements ..........................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Candidate Solution Methods and Needs ............................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Example Scenario ................................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. Normative References ............................................<a href="#page-8">8</a>
<a href="#section-8">8</a>. Informative References ..........................................<a href="#page-9">9</a>
<a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-10">10</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Voice over IP (VoIP) typically uses the encapsulation
voice/RTP/UDP/IP. When MPLS labels [<a href="#ref-MPLS-ARCH" title=""Multiprotocol Label Switching Architecture"">MPLS-ARCH</a>] are added, this
becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS Virtual Private
Network (VPN) (e.g., [<a href="#ref-MPLS-VPN" title=""BGP/MPLS VPNs"">MPLS-VPN</a>]), the packet header is at least 48
bytes, while the voice payload is often no more than 30 bytes, for
example. 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 [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>]
or robust header compression [<a href="#ref-ROHC" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed "">ROHC</a>], and also to increase scalability
of HC. We consider using MPLS to route compressed 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 flows that use HC at each router.
To implement HC over MPLS, the ingress router/gateway would have to
apply the HC algorithm to the IP packet, the compressed packet routed
on an MPLS LSP using MPLS labels, and the compressed header would be
decompressed at the egress router/gateway where the HC session
terminates. Figure 1 illustrates an HC over MPLS session established
on an LSP that crosses several routers, from R1/HC --> R2 --> R3 -->
R4/HD, where R1/HC is the ingress router where HC is performed, and
R4/HD is the egress router where header decompression (HD) is done.
HC of the RTP/UDP/IP header is performed at R1/HC, and the compressed
packets are routed using MPLS labels from R1/HC to R2, to R3, and
finally to R4/HD, without further decompression/recompression cycles.
The RTP/UDP/IP header is decompressed at R4/HD and can be forwarded
to other routers, as needed.
<span class="grey">Ash, et al. Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
| R2 |
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
| R3 |
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
Figure 1. Example of Header Compression over MPLS
over Routers R1-->R4
In the example scenario, HC therefore takes place between R1 and R4,
and the MPLS path transports voice/compressed-header/MPLS-labels
instead of voice/RTP/UDP/IP/MPLS-labels, typically saving 30 octets
or more per packet. The MPLS label stack and link-layer headers are
not compressed. A signaling method is needed to set up a
correspondence between the ingress and egress routers of the HC over
MPLS session.
In <a href="#section-2">Section 2</a> we give a problem statement, in <a href="#section-3">Section 3</a> we give goals
and requirements, and in <a href="#section-5">Section 5</a> we give an example scenario.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Problem Statement</span>
As described in the introduction, HC over MPLS can significantly
reduce the header overhead through HC mechanisms. The need for HC
may be important on low-speed links where bandwidth is more scarce,
but it could also be important on backbone facilities, especially
where costs are high (e.g., some global cross-sections). VoIP
typically will use voice compression mechanisms (e.g., G.729) on
<span class="grey">Ash, et al. Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
low-speed and international routes, in order to conserve bandwidth.
With HC, significantly more bandwidth could be saved. For example,
carrying uncompressed headers for the entire voice load of a large
domestic network with 300 million or more calls per day could consume
on the order of about 20-40 gigabits per second on the backbone
network for headers alone. This overhead could translate into
considerable bandwidth capacity.
The claim is often made that once fiber is in place, increasing the
bandwidth capacity is inexpensive, nearly 'free'. This may be true
in some cases; however, on some international cross-sections,
especially, facility/transport costs are very high and saving
bandwidth on such backbone links is very worthwhile. Decreasing the
backbone bandwidth is needed in some areas of the world where
bandwidth is very expensive. It is also important in almost all
locations to decrease the bandwidth consumption on low-speed links.
So although bandwidth is getting cheaper, the value of compression
does not go away. It should be further noted that IPv6 will increase
the size of headers, and therefore increase the importance of HC for
RTP flows.
Although hop-by-hop HC could be applied to decrease bandwidth
requirements, that implies a processing requirement for compression-
decompression cycles at every router hop, which does not scale well
for large voice traffic loads. The maximum number of compressed RTP
(cRTP) flows is about 30-50 for a typical customer premise router,
depending upon its uplink speed and processing power, while the need
may exceed 300-500 for a high-end case. Therefore, HC over MPLS
seems to be a viable alternative to get the compression benefits
without introducing costly processing demands on the intermediate
nodes. By using HC over MPLS, routers merely forward compressed
packets without doing a decompression/recompression cycle, thereby
increasing the maximum number of simultaneous compressed flows that
routers can handle.
Therefore, the proposal is to use existing HC techniques, together
with MPLS labels, to make the transport of the RTP/UDP/IP headers
more efficient over an MPLS network. However, at this time, there
are no standards for HC over MPLS, and vendors have not implemented
such techniques.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Specification of Requirements</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="#ref-KEY" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEY</a>].
<span class="grey">Ash, et al. Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Goals and Requirements</span>
The goals of HC over MPLS are as follows:
a. provide more efficient voice transport over MPLS networks,
b. increase the scalability of HC to a large number of flows,
c. not significantly increase packet delay, delay variation, or loss
probability, and
d. leverage existing work through use of standard protocols as much
as possible.
Therefore the requirements for HC over MPLS are as follows:
a. MUST use existing protocols (e.g., [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>], [<a href="#ref-ROHC" title=""RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed "">ROHC</a>]) to compress
RTP/UDP/IP headers, in order to provide for efficient transport,
tolerance to packet loss, and resistance to loss of session
context.
b. MUST allow HC over an MPLS LSP, and thereby avoid hop-by-hop
compression/decompression cycles (e.g., [<a href="#ref-HC-MPLS-PROTO" title=""Protocol Extensions for Header Compression over MPLS"">HC-MPLS-PROTO</a>]).
c. MUST minimize incremental performance degradation due to increased
delay, packet loss, and jitter.
d. MUST use standard protocols to signal context identification and
control information (e.g., [<a href="#ref-RSVP" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RSVP</a>], [<a href="#ref-RSVP-TE" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RSVP-TE</a>], [<a href="#ref-LDP" title=""LDP Specification"">LDP</a>]).
e. Packet reordering MUST NOT cause incorrectly decompressed packets
to be forwarded from the decompressor.
It is necessary that the HC method be able to handle out-of-sequence
packets. MPLS [<a href="#ref-MPLS-ARCH" title=""Multiprotocol Label Switching Architecture"">MPLS-ARCH</a>] enables 4-byte labels to be appended to IP
packets to allow switching from the ingress Label Switching Router
(LSR) to the egress LSP on an LSP through an MPLS network. However,
MPLS does not guarantee that packets will arrive in order at the
egress LSR, since a number of things could cause packets to be
delivered out of sequence. For example, a link failure could cause
the LSP routing to change, due perhaps to an MPLS fast reroute taking
place, or to the Interior Gateway Protocol (IGP) and Label
Distribution Protocol (LDP) converging to another route, among other
possible reasons. Other causes could include IGP reroutes due to
'loose hops' in the LSP, or BGP route changes reflecting back into
IGP reroutes. HC algorithms may be able to handle reordering
magnitudes on the order of about 10 packets, which may make the time
required for IGP reconvergence (typically on the order of seconds)
untenable for the HC algorithm. On the other hand, MPLS fast reroute
may be fast enough (on the order of 50 ms or less) for the HC
algorithm to handle packet reordering. The issue of reordering needs
to be further considered in the development of the HC over MPLS
solution.
<span class="grey">Ash, et al. Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
Resynchronization and performance also needs to be considered, since
HC over MPLS can sometimes have multiple routers in the LSP.
Tunneling an HC session over an MPLS LSP with multiple routers in the
path will increase the round-trip delay and the chance of packet
loss, and HC contexts may be invalidated due to packet loss. The HC
error recovery mechanism can compound the problem when long round-
trip delays are involved.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Candidate Solution Methods and Needs</span>
[<a id="ref-cRTP">cRTP</a>] performs best with very low packet error rates on all hops of
the path. When the cRTP decompressor context state gets out of synch
with the compressor, it will drop packets associated with the context
until the two states are resynchronized. To resynchronize context
state at the two ends, the decompressor transmits the CONTEXT_STATE
packet to the compressor, and the compressor transmits a FULL_HEADER
packet to the decompressor.
[<a id="ref-ECRTP">ECRTP</a>] uses mechanisms that make cRTP more tolerant to packet loss,
and ECRTP thereby helps to minimize the use of feedback-based error
recovery (CONTEXT_STATE packets). ECRTP is therefore a candidate
method to make HC over MPLS more tolerant of packet loss and to guard
against frequent resynchronizations. ECRTP may need some
implementation adaptations to address the reordering requirement in
<a href="#section-3">Section 3</a> (requirement e), since a default implementation will
probably not meet the requirement. ECRTP protocol extensions may be
required to identify FULL_HEADER, CONTEXT_STATE, and compressed
packet types. [<a href="#ref-cRTP-ENCAP" title=""IP Header Compression over PPP"">cRTP-ENCAP</a>] specifies a separate link-layer packet
type defined for HC. Using a separate link-layer packet type avoids
the need to add extra bits to the compression header to identify the
packet type. However, this approach does not extend well to MPLS
encapsulation conventions [<a href="#ref-MPLS-ENCAP" title=""MPLS Label Stack Encoding"">MPLS-ENCAP</a>], in which a separate link-
layer packet type translates into a separate LSP for each packet
type. In order to extend ECRTP to HC over MPLS, each packet type
defined in [<a href="#ref-ECRTP" title=""Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering"">ECRTP</a>] would need to be identified in an appended packet
type field in the ECRTP header.
[<a id="ref-ROHC">ROHC</a>] is also very tolerant of packet loss, and therefore is a
candidate method to guard against frequent resynchronizations. ROHC
also achieves a somewhat better level of compression as compared to
ECRTP. ROHC may need some implementation adaptations to address the
reordering requirement in <a href="#section-3">Section 3</a> (requirement e), since a default
implementation will probably not meet the requirement (see
[<a href="#ref-ROHC-REORD" title=""RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets"">ROHC-REORD</a>]). ROHC already has the capability to identify the
packet type in the compression header, so no further extension is
needed to identify packet type.
<span class="grey">Ash, et al. Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
Extensions to MPLS signaling may be needed to identify the LSP from
HC to HD egress point, negotiate the HC algorithm used and protocol
parameters, and negotiate the Session Context IDs (SCIDs) space
between the ingress and egress routers on the MPLS LSP. For example,
new objects may need to be defined for [<a href="#ref-RSVP-TE" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RSVP-TE</a>] to signal the SCID
spaces between the ingress and egress routers, and the HC algorithm
used to determine the context; these HC packets then contain the SCID
identified by using the RSVP-TE objects. It is also desirable to
signal HC over MPLS tunnels with the Label Distribution Protocol
[<a href="#ref-LDP" title=""LDP Specification"">LDP</a>], since many <a href="./rfc2547">RFC 2547</a> VPN [<a href="#ref-MPLS-VPN" title=""BGP/MPLS VPNs"">MPLS-VPN</a>] implementations use LDP as
the underlying LSP signaling mechanism, and LDP is very scalable.
However, extensions to LDP may be needed to signal SCIDs between
ingress and egress routers on HC over MPLS LSPs. For example,
'targeted LDP sessions' might be established for signaling SCIDs, or
perhaps methods described in [<a href="#ref-LDP-PWE3" title=""Pseudowire Setup and Maintenance using the Label Distribution Protocol"">LDP-PWE3</a>] to signal pseudo-wires and
multipoint-to-point LSPs might be extended to support signaling of
SCIDs for HC over MPLS LSPs. The specific MPLS signaling protocol
extensions to support these approved requirements need to be
developed as a well-coordinated separate document in the appropriate
IETF working groups. The IETF needs to support a coordinated process
for the two solution documents, though they are in separate areas.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Example Scenario</span>
As illustrated in Figure 2, many VoIP flows are originated from
customer sites, which are served by routers R1, R2, and R3, and
terminated at several large customer call centers, which are served
by R5, R6, and R7. R4 is a service-provider router, and all VoIP
flows traverse R4. It is essential that the R4-R5, R4-R6, and R4-R7
low-speed links all use HC to allow a maximum number of simultaneous
VoIP flows. To allow processing at R4 to handle the volume of
simultaneous VoIP flows, it is desired to use HC over MPLS for these
flows. With HC over MPLS, R4 does not need to do HC/HD for the flows
to the call centers, enabling more scalability of the number of
simultaneous VoIP flows with HC at R4.
<span class="grey">Ash, et al. Informational [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
voice/C-HDR/MPLS-labels ______ voice/C-HDR/MPLS-labels
R1/HC---------------------->| |-----------------------> R5/HD
| |
voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels
R2/HC---------------------->| R4 |-----------------------> R6/HD
| |
voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels
R3/HC---------------------->|______|-----------------------> R7/HD
Note: HC = header compression
C-HDR = compressed header
HD = header decompression
Figure 2. Example Scenario for Application of HC over MPLS
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The high processing load of HC makes HC a target for denial-of-
service attacks. For example, an attacker could send a high-
bandwidth data stream through a network, with the headers in the data
stream marked appropriately to cause HC to be applied. This would
use large amounts of processing resources on the routers performing
compression and decompression, and these processing resources might
then be unavailable for other important functions on the router.
This threat is not a new threat for HC, but is addressed and
mitigated by HC over MPLS. That is, by reducing the need for
performing compression and decompression cycles, as proposed in this
document, the risk of this type of denial-of-service attack is
reduced.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Normative References</span>
[<a id="ref-cRTP">cRTP</a>] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", <a href="./rfc2508">RFC 2508</a>,
February 1999.
[<a id="ref-cRTP-ENCAP">cRTP-ENCAP</a>] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP
Header Compression over PPP", <a href="./rfc3544">RFC 3544</a>, July 2003.
[<a id="ref-ECRTP">ECRTP</a>] Koren, T., Casner, S., Geevarghese, J., Thompson, B.,
and P. Ruddy, "Enhanced Compressed RTP (CRTP) for
Links with High Delay, Packet Loss and Reordering",
<a href="./rfc3545">RFC 3545</a>, July 2003.
[<a id="ref-KEY">KEY</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Ash, et al. Informational [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
[<a id="ref-LDP">LDP</a>] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", <a href="./rfc3036">RFC 3036</a>, January
2001.
[<a id="ref-MPLS-ARCH">MPLS-ARCH</a>] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", <a href="./rfc3031">RFC</a>
<a href="./rfc3031">3031</a>, January 2001.
[<a id="ref-ROHC">ROHC</a>] Bormann, C., et al., "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP,
and uncompressed ", <a href="./rfc3095">RFC 3095</a>, July 2001.
[<a id="ref-RSVP">RSVP</a>] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", <a href="./rfc2205">RFC 2205</a>,
September 1997.
[<a id="ref-RSVP-TE">RSVP-TE</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Informative References</span>
[<a id="ref-HC-MPLS-PROTO">HC-MPLS-PROTO</a>] Ash, G., Goode, B., Hand, J., Jonsson, L-E., Malis,
A., and R. Zhang, "Protocol Extensions for Header
Compression over MPLS", work in progress.
[<a id="ref-LDP-PWE3">LDP-PWE3</a>] Martini, L., El-Aawar, N., Smith, T., and G. Heron,
"Pseudowire Setup and Maintenance using the Label
Distribution Protocol", work in progress.
[<a id="ref-MPLS-ENCAP">MPLS-ENCAP</a>] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", <a href="./rfc3032">RFC 3032</a>, January 2001.
[<a id="ref-MPLS-VPN">MPLS-VPN</a>] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", <a href="./rfc2547">RFC 2547</a>,
March 1999.
[<a id="ref-ROHC-REORD">ROHC-REORD</a>] Pelletier, G., Jonsson, L-E., and K. Sandlund,
"RObust Header Compression (ROHC): ROHC over Channels
that can Reorder Packets", work in progress.
<span class="grey">Ash, et al. Informational [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors wish to thank the following people (in alphabetical
order) for their helpful comments and suggestions: Loa Andersson,
Scott Brim, Thomas Eriksson, Victoria Fineberg, Lars-Erik Jonsson,
Allison Mankin, Colin Perkins, Kristofer Sandlund, and Magnus
Westerlund.
Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-4578
EMail: [email protected]
Bur Goode
AT&T
Phone: + 1 203-341-8705
EMail: [email protected]
Jim Hand
AT&T
Room MT A2-1A03
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-3017
EMail: [email protected]
Raymond Zhang
BT Infonet
2160 E. Grand Ave.
El Segundo, CA 90025 USA
EMail: [email protected]
<span class="grey">Ash, et al. Informational [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc4247">RFC 4247</a> Requirements for Header Compression over MPLS November 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ash, et al. Informational [Page 11]
Annotations
Select text to annotate