One document matched: draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
Network Working Group Jerry Ash
Internet Draft Bur Goode
<draft-ash-avt-ecrtp-over-mpls-protocol-00.txt> Jim Hand
Expiration Date: August 2004 AT&T
George Swallow
Cisco Systems, Inc.
February, 2004
Protocol Extensions for ECRTP over MPLS
<draft-ash-avt-ecrtp-over-mpls-protocol-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
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 at least 48 bytes, while the voice payload is often
no more than 30 bytes, for example. VoIP header compression can
significantly reduce the VoIP overhead through various compression
mechanisms, such as enhanced compressed RTP (ECRTP). We consider using
MPLS to route ECRTP compressed packets over an MPLS LSP without
compression/decompression cycles at each router. Such an ECRTP over MPLS
capability can increase the bandwidth efficiency as well as processing
scalability of the maximum number of simultaneous VoIP flows that use
header compression at each router. In this draft we propose to use
RSVP-TE extensions to signal the header compression context and other
control messages between the ingress and egress LSR. We re-use the
methods in ECRTP to determine the context.
Table of Contents
1. Introduction
2. Requirements
3. Protocol Extensions
3.1 ECRTP over MPLS Header Compression & Call Flows
3.2 Link Layer Packet Type Field
3.3 Header Compression Object Formats
3.3.1 SCID_Request Object
3.3.2 Header_Compression_Reply Object
3.4 Control Plane Procedures
3.4.1 ECRTP over MPLS Procedures
3.4.2 Resource Reservation Procedures
3.5 Data Plane Procedures
4. Security Considerations
5. Acknowledgments
6. IANA Considerations
7. References
8. Intellectual Property Statement
9. Authors' Addresses
10. Full Copyright Statement
1. Introduction
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP.
When MPLS labels [MPLS-ARCH] are added, this becomes
voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN (e.g., [MPLS-VPN], the
packet header is at least 48 bytes, while the voice payload is often no
more than 30 bytes, for example. The interest in VoIP header
compression is to exploit the possibility of significantly reducing the
VoIP overhead through various compression mechanisms, such as with
enhanced compressed RTP [ECRTP], and also to increase scalability of
VoIP header compression. We consider using MPLS to route ECRTP
compressed packets over an MPLS LSP (label switched path) without
compression/decompression cycles at each router. Such an ECRTP over
MPLS capability can increase bandwidth efficiency as well as the
processing scalability of the maximum number of simultaneous VoIP flows
that use header compression at each router.
To implement ECRTP over MPLS, the ingress router/gateway would have to
apply the ECRTP 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 ECRTP session
terminates. Figure 1 illustrates an ECRTP 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 header compression (HC)
is performed, and R4/HD is the egress router where header decompression
(HD) is done. ECRTP 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.
_____
| |
|R1/HC| ECRTP Header Compression (HC) Performed
|_____|
|
| voice/ECRTP/MPLS-labels
V
_____
| |
| R2 |
|_____|
|
| voice/ECRTP/MPLS-labels
V
_____
| |
| R3 |
|_____|
|
| voice/ECRTP/MPLS-labels
V
_____
| |
|R4/HD| ECRTP Header Decompression (HD) Performed
|_____|
Figure 1. Example of ECRTP over MPLS over Routers R1 --> R4
In the example scenario, ECRTP header compression therefore takes place
between R1 and R4, and the MPLS path transports voice/ECRTP/MPLS-labels
instead of voice/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet.
The MPLS label stack and link-layer headers are not compressed.
Therefore ECRTP over MPLS can significantly reduce the VoIP header
overhead through compression mechanisms. The need for compression 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 low-speed and
international routes, in order to conserve bandwidth. With VoIP header
compression, significantly more bandwidth could be saved. For example,
carrying VoIP 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 header compression for VoIP flows.
While hop-by-hop header compression 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 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, ECRTP over MPLS seems to be a
viable alternative to get the compression benefits without introducing
costly processing demands on the intermediate nodes. By using ECRTP
over MPLS, routers merely forward compressed packets without doing a
decompression/recompression cycle, thereby increasing the maximum number
of simultaneous VoIP compressed flows that routers can handle.
Therefore the proposal is to use existing header compression techniques,
such as those described in [ECRTP], together with MPLS labels, to make
the transport of the RTP/UDP/IP headers more efficient over an MPLS
network. A method is needed to set up a correspondence between the
header compression tables at the ingress and egress routers of the ECRTP
over MPLS session. Therefore additional signaling is needed to map the
context for the compressed packets. However, at this time, there are no
standards for ECRTP over MPLS, and vendors have not implemented such
techniques.
In Section 2 we give goals and requirements, and Section 3 presents the
proposed protocol extensions.
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 [KEY].
2. Goals & Requirements
The requirements for ECRTP over MPLS [ECRTP-MPLS-REQ] are that it must:
a. Use existing protocols such as ECRTP and/or ROHC to compress
RTP/UDP/IP headers, in order to provide for efficient voice transport,
tolerance to packet loss, and resistance to loss of session context.
b. Allow ECRTP over an MPLS LSP, and thereby avoid hop-by-hop
compression/decompression cycles.
c. Minimize incremental performance degradation due to increased delay,
packet loss, and jitter.
d. Use standard protocols to signal context identification and control
information (e.g., [RSVP-TE]).
[ECRTP] should be used to make ECRTP over MPLS more tolerant of packet
loss, to guard against frequent resynchronizations, and to minimize the
need for error recovery. Protocol extensions are required for [ECRTP]
in that a packet type field is needed to identify FULL_HEADER,
CONTEXT_STATE, and compressed packets. For example, [cRTP-ENCAP]
specifies a separate link-layer packet type defined for header
compression. Using a separate link-layer packet type for every packet
type used in header compression avoids the need to add extra bits to the
compression header to identify the packet type. However, this practice
does not extend well to MPLS encapsulation conventions [MPLS-ENCAP], in
which a separate link-layer packet type translates into a separate LSP
for each packet type. In order to extend ECRTP to ECRTP over MPLS, each
packet type defined in [ECRTP] would need to be identified in an
appended packet type field in the ECRTP header.
Extensions to MPLS signaling are needed to signal the session context
IDs (SCIDs) between the ingress and egress routers on the MPLS LSP. For
example, new objects need to be defined for [RSVP-TE] to signal the
SCIDs between the ingress and egress routers, and [ECRTP] used to
determine the FULL_HEADER packets for the context identification; these
FULL HEADER packets then contain the SCID identified by using the
RSVP-TE objects. These protocol extensions need coordination with other
working groups (e.g., MPLS).
3. Protocol Extensions
3.1 ECRTP over MPLS Header Compression & Call Flows
The goal of ECRTP header compression is to reduce the IP/UDP/RTP headers
to 4 bytes for most packets, since ECRTP requires that the UDP checksums
be sent. In ECRTP header compression, the first factor-of-two 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 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
SCID, to indicate in which session context that packet should be
interpreted. Since compressed packets are assumed to be routed on a
separate LSP, set up by RSVP-TE, the decompressor uses the incoming MPLS
label and the SCID to locate the proper decompression context.
In Figure 1 we assume an example VoIP flow set up from R1/HC --> R2 -->
R3 --> R4/HD, where R1/HC is the ingress router where header compression
(HC) is performed, and R4/HD is the egress router where header
decompression (HD) is done, and in the reverse direction. Each router
functions as an LSR and supports RSVP-TE signaling of LSPs. A summary
of the VoIP call setup is as follows:
1. R1/HC sends an RSVP-TE PATH message to R4/HD, which includes a
SCID_Request object with a 2-byte VoIP-Call-ID.
2. R4/HD assigns a unique 2-byte SCID to the call and sends an RSVP-TE
RESV message to R1/HC that includes a Header_Compression_Reply object
with the VoIP-Call-ID and the assigned SCID.
3. R1/HC sets the SCID in compressed packets and FULL_HEADER packets.
4. Compressed packets and header compression control packets
(FULL_HEADER and CONTEXT_STATE packets) are routed on a separate LSP,
set up by RSVP-TE, from non-compressed packets; FULL-HEADER packets are
routed on the same R1/HC --> R4/HD LSP as the R1/HC to R4/HD compressed
packets for the VoIP call; CONTEXT-STATE packets are routed on the same
R4/HD --> R1/HC LSP as the R4/HD to R1/HC compressed packets for the
VoIP call.
5. compressed packets, FULL_HEADER packets, and CONTEXT_STATE packets
are routed with MPLS labels.
6. R4/HD uses the incoming MPLS label and the SCID to locate the proper
decompression context.
7. if needed to resync, R4/HD sends a CONTEXT_STATE packet to R1/HC with
SCID set; R1/HC resends FULL_HEADER packet with SCID set to R4/HD, etc.
8. R4/HD frees up the SCID when the VoIP call disconnects (as indicated
by SIP BYE message and RSVP-TE/PATH-TEAR messages), or by refreshing the
PATH state.
3.2 Link Layer Packet Type Field
The encodings in ECRTP use a different link layer packet type field for
each of 9 ECRTP packet types. Since it is necessary to identify packet
types for ECRTP packets over MPLS (e.g., FH packets and compressed
packets), it is proposed in this Section to add a 4-bit packet type
field in the ECRTP header to encode the 9 different packet types.
[cRTP-ENCAP] uses a separate link-layer packet type defined for header
compression. Using a separate link-layer packet type for every packet
type used in header compression avoids the need to add extra bits to the
compression header to identify the packet type. However, this practice
does not extend well to MPLS encapsulation conventions [MPLS-ENCAP], in
which a separate link-layer packet type translates into a separate LSP
for each packet type. So for ECRTP over MPLS VPNs, each packet type
defined in ECRTP MUST have prepended to it a packet type field. This
field adds 1 octet to the header, and is encoded as follows (most
significant bit is 0):
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Packet Type | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
"Packet Type" is encoded with the following values:
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
"Resvd" is reserved and must be set to 0.
3.3 Header Compression Object Formats
A new L3PID (ethertype), XXXX, is defined in [RSVP-TE] for ECRTP over
MPLS LSPs. This is needed to define the type of traffic used in RSVP-TE
Label Request Objects. An SCID_Request object and
Header_Compression_Reply object are defined in this section. R1/HC
creates an LSP to R4/HD by creating an RSVP-TE PATH message that
contains:
a. Label_Request object with the L3PID for ECRTP over MPLS (XXXX - TBD),
b. an SCID_Request object.
R1/HC will receive a RESV message containing a Label object and a
Header_Compression_Reply object. R1/HC uses the label and SCID to send
compressed traffic to R2/HD.
3.3.1 SCID_Request Object
The Class for Header Compression Objects is of the form 10bbbbbb (need
an official number from IANA). The form 10bbbbbb allows intermediate
nodes which do not understand header compression to silently drop the
compression object. This ensures that an LSP either exists between the
source and the destination or that header compression is disabled.
Class = Header Compression Object, Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num VoIP-Calls | VoIP-Call-IDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VoIP-Call-IDs Continued | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.2 Header_Compression_Reply Object
The presence of this object in a RESV message indicates that the
receiver will act as a decompressor for packets sent on this LSP which
contain one of the listed SCIDs. Over the life of an RSVP-TE session
SCIDs may be added and deleted simply by refreshing the PATH state with
the updated set of objects This object provides synchronization between
the sender and receiver as to which SCIDs may be used.
Class = Header Compression Object, Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num SCIDs | SCIDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCIDs Continued | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VoIP-Call-IDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VoIP-Call-IDs Continued | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.4 Control Plane Procedures
There are two logically separate functions in the control plane, call
control and bearer control.
Call control establishes, modifies, and releases telephone calls (e.g.,
using SIP). In distributed VoIP architectures, call agents control
media gateways (e.g., using Megaco/H.248) to obtain the IP address of
the terminating GW and determine what processing functions the media GW
must apply to the media stream (e.g., codec choice, echo cancellation,
etc.).
Bearer control establishes, modifies, and releases the logical
bearer-path connection between gateways (e.g., using RSVP-TE), allowing
a bandwidth reservation to be established before called party alerting,
and giving the originating GW the capability to reject a call if quality
would be unacceptable. RSVP-TE also needs to establish and control the
ECRTP over MPLS header compression context, as described in the previous
Section. RSVP-TE bearer control and SIP call control need to be
coordinated in setting up a call.
The MPLS control-plane uses RSVP-TE to a) establish LSPs and label
bindings between each GW-GW pair, b) to establish and control ECRTP over
MPLS, and c) to provide resource reservation and bandwidth allocation
for the varying number of calls on a GW-GW pair. ECRTP over MPLS
control and resource reservation procedures are now further described.
3.4.1 ECRTP over MPLS Procedures
The following procedures apply only to unicast sessions (extension to
multicast is for further study) and discuss processing at the source,
intermediate and destination nodes.
ECRTP over MPLS is always initiated by the originator of the PATH
message, which we refer to as the source. Note that the initiator of
the RSVP-TE session may or may not be the ultimate source of the
compressed flow. For instance a Cable Modem Termination System (CMTS)
in a packet cable environment might serve as the compressor for a VoIP
flow across an MPLS backbone.
The source requests SCID assignments from the decompressor and the
decompressor assigns the SCIDs.
For ECRTP header compression, the compressor and decompressor follow the
procedures in [ECRTP], including the sending of FULL-HEADER packets,
compressed packets, CONTEXT_STATE packets, etc.
Compressed packets and header compression control packets (FULL_HEADER
and CONTEXT_STATE packets) are routed on a separate LSP, set up by
RSVP-TE, from non-compressed packets. FULL-HEADER packets are routed on
the same R1/HC --> R4/HD LSP as the R1/HC to R4/HD compressed packets
for the VoIP call. CONTEXT-STATE packets are routed on the same R4/HD
--> R1/HC LSP as the R4/HD to R1/HC compressed packets for the VoIP
call.
The SCID-Request Object is included in an RSVP-TE PATH message. This
object MUST not be included if a LABEL_REQUEST object is not also
included in the PATH message.
Intermediate nodes must act to ensure that an LSP exists from source to
destination. Thus if an intermediate node forwards a PATH message
without a label request, the node MUST drop the HC Object from the PATH
message. The HC object class is set to a value which indicates to nodes
in the PATH which do not understand the object that they are to silently
drop the object. This has the effect of allowing the RSVP-TE session
while disabling header compression. This ensures that a HC unaware node
will not inadvertently allow a discontinuity in the LSP.
If the destination node receives a PATH message with HC objects and is
willing to act as a decompressor for this session and these
VoIP-Call-IDs, it includes the SCIDs in a HC_REPLY object in the
corresponding RESV message.
3.4.2 Resource Reservation Procedures
As illustrated in Figure 2, each voice call requires two reservations,
because the reservation and admission control mechanisms provided by
RSVP-TE are unidirectional.
Originating Gateway/ Terminating Gateway/
Ingress LSR Egress LSR
| |
|----------------(1) INVITE----------------->|
| |
|<--------(2) 183_SESSION_PROGRESS ----------|
| |
|<---------------(3) PATH -------------------|
| |
|----------------(4) PATH ------------------>|
| |
|<---------------(5) RESV -------------------|
| |
|----------------(6) RESV ------------------>|
| |
|----------(7) RESV_CONFIRMATION------------>|
| |
|<------------(8) 180_RINGING----------------|
| |
|<--------------(9) 200_OK-------------------|
| |
|----------------(10) BYE------------------->|
| |
|-------------(11) PATH_TEAR---------------->|
| |
|<------------(12) RESV_TEAR-----------------|
| |
|<------------(13) PATH_TEAR-----------------|
| |
|-------------(14) RESV_TEAR---------------->|
Figure 2 - Call Setup with RSVP-TE & SIP
To set up the call, for example using SIP [SIP, SIP-CALL] and RSVP-TE,
the originating GW sends a SIP INVITE message to the destination GW.
The destination GW responds to the INVITE message with a SIP
183_SESSION_PROGRESS message, and also sends a RSVP-TE PATH message
along the reverse path back to the originating GW. The originating GW
also sends a RSVP-TE PATH message to the destination GW along the path
that the voice packets will take. The PATH messages include the HC
objects for ECRTP context identification and control, as described in
Section 3.2. The destination GW holds the call setup process in
abeyance waiting for the reservation results for both directions of
proposed VoIP packet flow. Upon receipt of the PATH messages, each GW
sends a RESV message along the path in the reverse direction, with the
HC objects described in Section 3.2. Each RSVP-TE-activated router
along the path makes a decision whether there is enough bandwidth to
admit the call.
When the originating GW receives a positive RESV message, it knows that
there is enough capacity along the path to the destination GW, and it
sends an RSVP-TE RESV_CONFIRMATION message to the destination GW. When
the destination GW receives a positive RESV message, it knows that there
is enough capacity along the path to the originating GW. When the
destination GW has determined that there is enough capacity in both
directions, it lets call setup continue and sends a SIP 180_RINGING
message to the originating GW and then a 200_OK message after the call
is answered. If this process determines that there is insufficient
capacity, the call is blocked.
The GW initiates a normal disconnect by sending a SIP BYE message. The
gateways tear down their reservations by sending RSVP-TE PATH_TEAR and
RESV_TEAR messages. If a GW fails or a link failure leads to unilateral
disconnection, the reservation will time out when the routers fail to
receive reservation refresh messages.
3.5 Data Plane Procedures
The source node compresses the header by removing the header and forming
the compressed header, which is prepended to the remainder of the
packet. The SCID and the MPLS header are then prepended and the packet
is sent. Note that the compressor MUST not use a SCID until it has
received a RESV message which contains a HC_REPLY with the SCID listed.
The destination node removes the MPLS header and the compressed header.
The node prepends the header template to the packet and then uses the
operands to populate the variable fields of the header with the values
sent in the compressed header.
For ECRTP header compression, the compressor and decompressor follow the
procedures in [ECRTP], including the sending of FULL-HEADER packets,
compressed packets, CONTEXT_STATE packets, etc.
4. Security Considerations
These procedures do not change the trust model of [RSVP] and [RSVP-TE].
As such no additional security risks are posed.
5. Acknowledgements
6. IANA Considerations
As discussed in Section 3.2, a new L3PID (ethertype), XXXX, needs to be
assigned for ECRTP over MPLS LSPs.
7. References
[cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999.
[cRTP-ENCAP] Engan, M., Casner, S., Bormann, C., "IP Header Compression
over PPP", RFC 2509, February 1999.
[ECRTP] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links
with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.
[ECRTP-MPLS-REQ] Ash, G., Goode, B., Hand, J., "Requirements for ECRTP
over MPLS", work in progress.
[GVPLS] Radoaca, V., et. al., "GVPLS/LPE - Generalized VPLS Solution
based on LPE Framework," work in progress.
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[LDP] Andersson, L., et. al., "LDP Specification", RFC 3036, January
2001.
[LDP-PWE3] Martini, L., et. al., "Pseudowire Setup and Maintenance using
LDP", work in progress.
[MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching
Architecture," RFC 3031, January 2001.
[MPLS-ENCAP] Rosen, E., et. al., "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
1999.
[ROHC] Bormann, C., et. al., "Robust Header Compression (ROHC)," RFC
3091, July 2001.
[RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205, September 1997.
[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in RFC 2028. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
9. 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
E-mail: bgoode@att.com
Jim Hand
AT&T
E-mail: hand17@earthlink.net
George Swallow
Cisco Systems, Inc.
250 Apollo Drive Chelmsford, MA 01824
Phone: +1 978 497 8143
Email: swallow@cisco.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.
| PAFTECH AB 2003-2026 | 2026-04-24 06:03:11 |