One document matched: draft-ash-avt-hc-over-mpls-protocol-01.txt
Differences from draft-ash-avt-hc-over-mpls-protocol-00.txt
Network Working Group Jerry Ash
Internet Draft Bur Goode
<draft-ash-avt-hc-over-mpls-protocol-01.txt> AT&T
Expiration Date: January 2006 Jim Hand
Consultant
L-E. Jonsson
Ericsson
Andrew Malis
Tellabs
Raymond Zhang
Infonet
July, 2005
Protocol Extensions for Header Compression over MPLS
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 1]
Internet Draft Header Compression over MPLS Protocol July 2005
Abstract
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. MPLS is used to route header-compressed (HC)
packets over an MPLS LSP without compression/decompression cycles at
each router. Such an HC over MPLS capability increases the bandwidth
efficiency as well as processing scalability of the maximum number of
simultaneous compressed flows that use HC at each router. MPLS
pseudowires are used to transport the HC context and other control
messages between the ingress and egress MPLS label switched router
(LSR), and the pseudowires define a point to point instance of each
HC session at the header decompressor. Standard HC methods (e.g.,
ECRTP, ROHC, etc.) are re-used to determine the context.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Header Compression over MPLS Protocol Overview . . . . . . . . 6
3.1 PW Setup & HC Session Configuration . . . . . . . . . . . 7
3.2 HC over MPLS . . . . . . . . . . . . . . . . . . . . . . . 8
4. Protocol Specifications . . . . . . . . . . . . . . . . . . . 9
4.1 MPLS Pseudowire & Header Compression Scheme
Setup/Negotiation/Signaling . . . . . . . . . . . . . . . 9
4.2 Encapsulation of Header Compressed Packets . . . . . . . . 12
4.2.1 FULL_HEADER Packet Format . . . . . . . . . . . . . 13
4.2.2 CONTEXT_STATE Packet Format . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
9. Informative References . . . . . . . . . . . . . . . . . . . . 15
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 2]
Internet Draft Header Compression over MPLS Protocol July 2005
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 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
header compression. MPLS is used to route header-compressed (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 header compression at each router.
To implement HC over MPLS, after the ingress router applies the HC
algorithm to the IP packet, the compressed packet is forwarded on an
MPLS LSP using MPLS labels, and then the egress router restores the
uncompressed header. Figure 1 illustrates an HC over MPLS session
established on an LSP that traverses several label switch routers,
from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router
performing header compression (HC), and R4/HD is the egress router
performing header decompression (HD). Compression 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.
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 3]
Internet Draft Header Compression over MPLS Protocol July 2005
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| data (e.g. voice)/compressed-header/MPLS-labels
V
_____
| |
| R2 |
|_____|
|
| data (e.g. voice)/compressed-header/MPLS-labels
V
_____
| |
| R3 |
|_____|
|
| data (e.g. voice)/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
Figure 1. Example of HC over MPLS over Routers R1 --> R4
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. 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) are used to transport the header compressed packets
between the ingress and egress MPLS label switched router (LSR), and
the PWs define a point to point instance of each HC session at the
header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.)
are used to determine the context.
HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets.
Half of the reduction in header size comes from the observation that
half of the bytes in the IP/UDP/RTP headers remain constant over the
life of the connection. After sending the uncompressed header
template once, these fields may be removed from the compressed
headers that follow. The remaining compression comes from the
observation that although several fields change in every packet, the
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 4]
Internet Draft Header Compression over MPLS Protocol July 2005
difference from packet to packet is often constant and therefore the
second-order difference is zero.
By maintaining both the uncompressed header and the first-order
differences in the session state shared between the compressor and
decompressor, all that must be communicated is an indication that the
second-order difference was zero. In that case, the decompressor can
reconstruct the original header without any loss of information
simply by adding the first-order differences to the saved
uncompressed header as each compressed packet is received. The
compressed packet carries the context identification (CID), to
indicate in which session context that packet should be interpreted.
Compressed data is routed on a separate MPLS LSP/PW from compressor
to decompressor, where the PW is set up by MPLS PW signaling
[PW-SIG]. The decompressor uses the incoming MPLS PW Label and the
CID to locate the proper decompression context.
Goals and requirements for header compression over MPLS are discussed
In [MPLS-HC-REQ]. The solution put forth in this document has been
Designed to address these goals and requirements.
2. Terminology
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 [RFC2119].
Forwarding Equivalence Class (FEC): a group of IP packets which are
forwarded in the same manner (e.g., over the same LSP, with the same
forwarding treatment)
Label: a short fixed length physically contiguous identifier which is
used to identify a FEC, usually of local significance
Label Switched Path (LSP): the path through one or more LSRs at one
level of the hierarchy followed by a packets in a particular
forwarding equivalence class (FEC)
Label Switching Router (LSR): an MPLS node which is capable of
forwarding native L3 packets label stack an ordered set of labels
MPLS domain: a contiguous set of nodes which operate MPLS routing
and forwarding and which are also in one Routing or Administrative
Domain
MPLS label: a label which is carried in a packet header, and which
represents the packet's FEC
MPLS node: a node that is running MPLS. An MPLS node will be aware
of MPLS control protocols, will operate one or more L3 routing
protocols, and will be capable of forwarding packets based on labels.
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 5]
Internet Draft Header Compression over MPLS Protocol July 2005
An MPLS node may optionally be also capable of forwarding native L3
packets.
MultiProtocol Label Switching (MPLS): an IETF working group and the
effort associated with the working group
Packet Switched Network (PSN): Within the context of PWE3, this is a
network using IP or MPLS as the mechanism for packet forwarding.
Protocol Data Unit (PDU): The unit of data output to, or received
from, the network by a protocol layer.
Pseudo Wire (PW): A mechanism that carries the essential elements of
an emulated service from one provider edge router to one or more
other provider edge routers over a PSN
Pseudo Wire Emulation Edge to Edge (PWE3): A mechanism that emulates
the essential attributes of service (such as a T1 leased line or
Frame Relay) over a PSN
Pseudo Wire PDU (PW-PDU): A PDU sent on the PW that contains all of
the data and control information necessary to emulate the desired
service
PSN Tunnel: A tunnel across a PSN, inside which one or more PWs can
be carried
PSN Tunnel Signaling: Used to set up, maintain, and tear down the
underlying PSN tunnel
PW Demultiplexer: Data-plane method of identifying a PW terminating
at a provider edge router
Tunnel: A method of transparently carrying information over a network
3. Header Compression over MPLS Protocol Overview
MPLS is used to route HC packets over an MPLS LSP without
compression/decompression cycles at each intermediate router. MPLS
pseudowires (PWs) are used to transport the header compressed packets
between the ingress and egress MPLS label switched router (LSR), and
the PWs define a point to point instance of each HC session at the
header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.)
are used to determine the context.
Traditionally, the use of HC over a particular link is a function of
the link-layer protocol, PPP, HDLC, FR, etc. Native procedures could
be used to carry compressed packets over a PW. That is, the
link-layer protocol could be emulated over the PW, which would then
behave like a serial link running encapsulated link-layer PDUs across
the MPLS network. The drawback of this approach is that the
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 6]
Internet Draft Header Compression over MPLS Protocol July 2005
compressed packet needs to be carried in a layer-2 PDU, which
requires extra overhead.
Alternatively, compressed packets are directly encapsulated over a
PW, and are routed across the MPLS network using MPLS labels, which
include the packet switched network (PSN) label and PW label. In
this approach, a PW control word is used to identify the type of
packet, a unique PW Type is defined for each HC scheme, and, as
normal, a context identification (CID) is used to identify each
compressed packet context and payload. Each HC scheme is applied
directly over its own PW type, and the principles of HC-over-PPP
[RFC3241, RFC3544] are re-used. This more efficient approach is
taken in this document, and is now summarized.
An MPLS PW allows protocol data units for various link-layer
protocols to be encapsulated and carried over an MPLS network. The
PW is set up by a PW signaling protocol [PW-SIG], and the Interface
Parameters Sub-TLV [IANA, PW-SIG] is used to convey HC configuration
information including HC session setup and HC parameter negotiation.
Mechanisms and principles for HC session setup and HC parameter
negotiation, as described for HC-over-PPP mechanisms [RFC3241,
RFC3544], are reused to enable HC session configuration.
MPLS PWs directly encapsulate compressed packets and HC control
packets, etc., for each HC scheme as identified by the PW type.
Mechanisms and principles described in each HC scheme: cTCP
[RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP
[RFC3545], are then directly reused to enable compressed packet
transport.
3.1 PW Setup & HC Session Configuration
From the signaling procedures from [PW-SIG], a PW is established
between the header compressor (HC) and header decompressor (HD) for
the transport of the media stream between the HC and HD endpoints.
Figure 2 illustrates header-compressed packets carried over a PW
through an MPLS LSP tunnel. The 'PW label' is used as the
demultiplexer field by the HD, where the PW label appears at the
bottom of an MPLS label stack.
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 7]
Internet Draft Header Compression over MPLS Protocol July 2005
|<------- Pseudowire -------->|
| |
| |<-- MPLS Tunnel -->| |
V V V V
+----+ +----+
| HC |===================| HD |
|............PW...............|
| |===================| |
+----+ +----+
Figure 2: Pseudowire (PW) Reference Configuration
PWs are set up for the transport of media streams based on [PW-SIG]
control messages exchanged by the endpoints. PWs for media streams
are established at the edges of the MPLS network. Furthermore, a PW
type indicates the HC scheme being used on the PW, as specified in
[IANA].
The PW HC approach in this document relies on the PW/MPLS layer to
convey HC session configuration information. As detailed in Section
4.1, the Interface Parameters Sub-TLV [IANA, PW-SIG] is used to
signal HC session setup and HC parameter negotiation, such as
described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The
principles and IPCP messages described in [RFC3241, RFC3544] are
reused to enable PW/MPLS HC session configuration, as the PPP layer
does for each of the HC mechanisms.
3.2 HC over MPLS
Since a PW in an MPLS network looks similar to a point-to-point link,
the same HC approaches used on point-to-point links may be used in
PW-MPLS networks, for example, when shipping IP/UDP/RTP traffic over
MPLS PWs. Existing HC algorithms are re-used, as specified in cTCP
[RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP
[RFC3545], to maintain contexts as per each HC scheme and route each
stream over the appropriate PW. This section describes how to carry
HC packets in a PW-MPLS network for real-time media streams.
Figure 3 shows the HC over MPLS protocol stack. The uncompressed
stack would be:
Media stream
RTP
UDP
IP
PW control octet
MPLS label stack (at least 2 labels for this application)
Link layer under MPLS (PPP, PoS, Ethernet)
Physical layer (SONET/SDH, fiber, copper)
Then we do compression on the IP/UDP/RTP headers before transmission,
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 8]
Internet Draft Header Compression over MPLS Protocol July 2005
leaving the rest of the stack alone, as shown in Figure 3:
+--------------+
| Media stream |
+--------------+
\_______ ______/
2-4 octets V
+------+--------------+
Compressed /RTP/UDP/IP/ |header| |
+------+--------------+
\__________ __________/
1 octet V
+------+---------------------+
PW Control Octet |header| |
+------+---------------------+
\______________ _____________/
8 octets V
+------+----------------------------+
MPLS Labels |header| |
+------+----------------------------+
\_________________ _________________/
V
+------+-----------------------------------+
Link Layer under MPLS |header| |
+------+-----------------------------------+
\____________________ _____________________/
V
+------+------------------------------------------+
Physical Layer |header| |
+------+------------------------------------------+
Figure 3 - Header Compression over MPLS Media Stream Transport
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. Note that ROHC
[RFC3095] provides its own packet type within the protocol, and does
not require use of the PW control octet. We illustrate formats of
the FULL_HEADER and CONTEXT_STATE packets in Section 4.2, Figures 6
and 7, respectively. The formats of other HC-control packets are
similarly encapsulated, and the PW control octet is set to the
appropriate value indicating the packet format.
4. Protocol Specifications
4.1 MPLS Pseudowire & Header Compression Scheme
Setup/Negotiation/Signaling
From the signaling procedures from [PW-SIG], a PW is established
between the header compressor (HC) and header decompressor (HD) for
the transport of the media stream between the HC and HD endpoints.
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 9]
Internet Draft Header Compression over MPLS Protocol July 2005
Figure 2 illustrates header-compressed packets carried over a PW
through an MPLS LSP tunnel. The 'PW label' is used as the
demultiplexer field by the HD, where the PW label appears at the
bottom label of an MPLS label stack. See [PW-SIG] for an explanation
of PW signaling, and [PW-HDLC-PPP] for a PW type that can be modeled
for the application in this document.
In Figure 2, many simultaneous compressed flows (could be 100's or
1000's) need to be established between HC and HD. These multiple
simultaneous compressed flows are carried on one HC-HD PW, and HD
uses the CID to identify the compressed flow-context and the PW
(inner) label to identify the HC source. That is, each HC-HD
compressed session would be identified by the PW label. The CIDs are
assigned by the HC as normal, and there would be no problem if
duplicate CIDs are received at the HD for different compressed
sessions. For example, if HC-a and HC-b assign the same CID to a
flow, each PW had a logically separate HD instance, in this case,
HD-a and HD-b, independent of all other PWs. That is, HD-a and HD-b
have a separate decompression context for the two flows based on the
PW label and CID mapping.
It is also possible for multiple PWs to be established in case
Different QoS requirements are needed for different compressed
streams. The QoS received by the flow would be determined by the EXP
bit marking in the PW label. Normally, all the RTP packets would get
the same EXP marking, equivalent to EF treatment in DiffServ.
However, the protocol specified in this document applies to other
than RTP streams, and QoS treatment other than EF may be required for
those streams.
PWs are set up for the transport of media streams based on [PW-SIG]
control messages exchanged by the endpoints. PWs for media streams
are established at the edges of the MPLS network. Furthermore, a PW
type indicates the HC scheme being used on the PW [IANA], as follows:
0x001B cTCP [RFC1144] Transport Header-compressed Packets
0x001C IPHC [RFC2507] Transport Header-compressed Packets
0x001D cRTP [RFC2508] Transport Header-compressed Packets
0x001E ROHC [RFC3095] Transport Header-compressed Packets
0x001F ECRTP [RFC3545] Transport Header-compressed Packets
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:
1. [PW-SIG] is used to create the R1 --> R4 LSP/PW that follows
R1 --> R2 --> R3 --> R4.
2. [PW-SIG] is used to create the R4 --> R1 LSP/PW that follows
R4 --> R3 --> R2 --> R1.
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 10]
Internet Draft Header Compression over MPLS Protocol July 2005
3. [RFC3544] and [RFC3241] are used to negotiate HC scheme
parameters, which is extended in this specification to negotiating
during PW setup, as specified in Section 4.1.
4. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to
send HC scheme control packets and compressed packets to R4/HC, with
LSP and PW labels.
5. R4/HD uses the incoming MPLS PW label and CID to locate the proper
decompression context to decompress the compressed packets sent by
R1/HC.
6. R4/HC assigns a CID to the flow and uses the R4 --> R1 LSP/PW to
send HC scheme control packets and compressed packets to R1/HD, with
LSP and PW labels.
7. R1/HD uses the incoming MPLS PW label and CID to locate the proper
decompression context to decompress the compressed packets sent by
R4/HC.
8. if needed to resync, R4/HD sends an appropriate HC scheme control
packet to R1/HC; R1/HC resends the appropriate HC scheme control
packet to R4/HD.
9. if needed to resync, R1/HD sends an appropriate HC scheme control
packet to R4/HC; R4/HC resends the HC scheme control packet to R1/HD.
10. Existing HC scheme procedures are used to assign and free up the
CIDs; see, for example, Section 7 in [ROHC-IMPL-GUIDE].
The PW HC approach in this document relies on the PW/MPLS layer to
convey HC session configuration information. The Interface
Parameters Sub-TLV [IANA, PW-SIG], illustrated in Figure 4, is used
to signal HC session setup and HC parameter negotiation, such as
described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The
principles and IPCP messages described in [RFC3241, RFC3544] are
reused to enable PW/MPLS HC session configuration, as the PPP layer
does for each of the HC mechanisms. This sub-TLV specifies interface
specific parameters, and is used to configure the HC and HD ports at
the edges of the PW, have the necessary capabilities to interoperate
with each other.
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
The interface parameter sub-TLV type values are specified in [IANA].
Type values are specified for both the network control protocol for
IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. IPCP and
IPV6CP TLVs may then be encapsulated in the PW Interface Parameters
Sub-TLV and used to negotiate HC parameters for their respective
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 11]
Internet Draft Header Compression over MPLS Protocol July 2005
protocols. The IPCP and IPV6CP TLVs supported in this manner include
the following:
o Configuration Option Format, RTP-Compression Suboption, Enhanced
RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as
specified in [RFC3544]
o Configuration Option Format, PROFILES Suboption, as specified in
[RFC3241]
4.2 Encapsulation of Header Compressed Packets
Since a PW in an MPLS network looks similar to a point-to-point link,
the same HC approaches used on point-to-point links may be used in
PW-MPLS networks, for example, when transmitting IP/UDP/RTP traffic
over MPLS PWs. Existing HC algorithms are re-used, as specified in
cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and
ECRTP [RFC3545], to maintain contexts as per each HC scheme and route
each stream over the appropriate PW. This section describes how to
carry HC packets in a PW-MPLS network for real-time media streams.
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
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
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 12]
Internet Draft Header Compression over MPLS Protocol July 2005
word [PW-CNTL-WORD].
Note that ROHC [RFC3095] provides its own packet type within the
protocol, and does not require use of the PW control octet. We
illustrate the exchange of packet formats for the case of [RFC2508],
the other HC approaches are similar.
FULL_HEADER - communicates a full IP/UDP/RTP header to establish or
synchronize the state in the de-compressor for a call context.
Similar to IP/UDP/RTP HC over PPP links [RFC2508], HC over MPLS PWs
requires a CID. Namely, the HC/HDs on both ends need to maintain
context for many IP flows traversing the same link and the CIDs are
used to determine the context in which a packet has to be considered.
CONTEXT_STATE - is a special packet sent from the HD to the HC
indicating that the context associated with the flow may have been
invalidated. The compressor is expected to send the next packet as a
FULL_HEADER packet.
We now illustrate the formats of the FULL_HEADER and CONTEXT_STATE
packets.
4.2.1 FULL_HEADER Packet Format
The format of a FULL_HEADER packet is illustrated in Figure 6, where
the PW control octet is set to '00000001' indicating a FULL_HEADER
packet format.
PW Control Octet
\_____ ________/
V
+----------+--------------------+--------------+
| 00000001 | /RTP/UDP/IP Header | Data |
+----------+--------------------+--------------+
\______________________ _______________________/
V
+----------------+----------------------------------------------+
| MPLS/PW Labels | MPLS-PDU |
+----------------+----------------------------------------------+
Figure 6 - FULL_HEADER Packet
4.2.2 CONTEXT_STATE Packet Format
The format of a CONTEXT_STATE packet is illustrated in Figure 7,
where the PW control octet is set to '00001001' indicating a
CONTEXT_STATE packet format.
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 13]
Internet Draft Header Compression over MPLS Protocol July 2005
PW Control Octet
\_____ ________/
V
+----------+--------------------+--------------+
| 00001001 | /RTP/UDP/IP Header | Data |
+----------+--------------------+--------------+
\______________________ _______________________/
V
+----------------+----------------------------------------------+
| MPLS/PW Labels | MPLS-PDU |
+----------------+----------------------------------------------+
Figure 7 - CONTEXT_STATE Packet
The formats of other HC-control packets are similarly encapsulated,
and the PW control octet is set to the appropriate value indicating
the packet format.
Packet reordering for ROHC and ECRTP are discussed in [ROHC-REORDER]
and [ECRTP-REORDER], which are a useful source of information. An
evaluation and simulation of ECRTP and ROHC reordering is given in
[REORDER-EVAL].
5. Security Considerations
MPLS pseudowire security considerations in general are discussed in
[RFC3985] and [PW-SIG], and those considerations also apply to this
document. This document specifies an encapsulation and not the
protocols that may be used to carry the encapsulated packets across
the PSN, or the protocols being encapsulated. Each such protocol may
have its own set of security issues, but those issues are not
affected by the encapsulations specified herein.
6. Acknowledgements
The authors appreciate valuable inputs and suggestions from Loa
Andersson, Stewart Bryant, Adrian Farrel, Victoria Fineberg, Colin
Perkins, George Swallow, Curtis Villamizar, and Magnus Westerlund.
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].
8. Normative References
[IANA] Martini, L., et. al., "IANA Allocations for Pseudo Wire Edge
To Edge Emulation (PWE3)," work in progress.
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 14]
Internet Draft Header Compression over MPLS Protocol July 2005
[MPLS-HC-REQS] Ash, G., Goode, B., Hand, J., "Requirements for Header
Compression over MPLS", work in progress.
[PW-PPP] Martini, L., et. al., "Encapsulation Methods for Transport
of PPP/HDLC Over IP and MPLS Networks," work in progress.
[PW-SIG] Martini, L., et. al., "Pseudowire Setup and Maintenance
Using LDP," work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP,"
RFC 3241, April 2002.
[RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression
over PPP", RFC 3544, July 2003.
9. Informative References
[ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath
Treatment in MPLS Networks," work in progress.
[ECRTP-REORDER] Koren, T., et. al., "Packet reordering in Extended
CRTP (ECRTP)," work in progress.
[PW-CNTL-WORD] Bryant, S., et. al., "PWE3 Control Word for use over
an MPLS PSN," work in progress.
[REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header
Compression Algorithm ECRTP,"
http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)," May 1992.
[RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507,
February 1999.
[RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
1999.
[RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC
3095, July 2001.
[RFC3545] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on
Links with High Delay, Packet Loss, and Reordering," RFC 3545, July
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 15]
Internet Draft Header Compression over MPLS Protocol July 2005
2003.
[RFC3985] Bryant, S., et. al., " Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture," RFC 3985, March 2005.
[ROHC-IMPL-GUIDE] Jonsson, L-E., Kremer, P. "ROHC Implementer's
Guide," work in progress.
[ROHC-REORDER] Pellitier, G., et. al., "RObust Header Compression
(ROHC): ROHC over Channels that can Reorder Packets," work in
progress.
10. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-4578
Email: gash@att.com
Bur Goode
AT&T
Phone: +1 203-341-8705
Email: bgoode@att.com
Jim Hand
Consultant
Phone : +1 732-532-3020
Email: James.Hand@mail1.monmouth.army.mil
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com
Andrew G. Malis
Tellabs
90 Rio Robles Dr.
San Jose, CA 95134
Email: Andy.Malis@tellabs.com
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
Email: zhangr@bt.infonet.com
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 16]
Internet Draft Header Compression over MPLS Protocol July 2005
Intellectual Property Statement
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 BCP 78 and BCP 79.
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
http://www.ietf.org/ipr.
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-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Ash, et. al. <draft-ash--avt-hc-over-mpls-protocol-01.txt> [Page 17]| PAFTECH AB 2003-2026 | 2026-04-24 06:03:06 |