Network Working Group Jerry Ash Internet Draft Bur Goode Jim Hand Expiration Date: August 2004 AT&T George Swallow Cisco Systems, Inc. February, 2004 Protocol Extensions for ECRTP over MPLS 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.