RFC4619
Network Working Group L. Martini, Ed. Request for Comments: 4619 Cisco Systems, Inc. Category: Standards Track C. Kawa, Ed.
Oz Communications
A. Malis, Ed.
Tellabs
September 2006
Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network.
7.9.1. Frame Relay Specific Interface Parameter Sub-TLV ...12
Contents
- 1 Introduction
- 2 Specification of Requirements
- 3 Co-authors
- 4 Acronyms and Abbreviations
- 5 Applicability Statement
- 6 General Encapsulation Method
- 7 Frame Relay over MPLS PSN for the One-to-One Mode
- 8 Frame Relay Port Mode
- 9 Congestion Control
Introduction
In an MPLS or IP network, it is possible to use control protocols such as those specified in RFC4447 to set up "pseudowires" (PWs) that carry the Protocol Data Units of layer 2 protocols across the network. A number of these emulated PWs may be carried in a single tunnel. The main functions required to support frame relay PW by a Provider Edge (PE) include:
- encapsulation of frame relay specific information in a suitable
pseudowire (PW) packet;
- transfer of a PW packet across an MPLS network for delivery to a
peer PE;
- extraction of frame relay specific information from a PW packet by
the remote peer PE;
- regeneration of native frame relay frames for forwarding across an
egress port of the remote peer PE; and
- execution of any other operations as required to support frame
relay service.
This document specifies the encapsulation for the emulated frame relay VC over an MPLS PSN. Although different layer 2 protocols require different information to be carried in this encapsulation, an attempt has been made to make the encapsulation as common as possible for all layer 2 protocols. Other layer 2 protocols are described in separate documents. [ATM] RFC4448 RFC4618
The following figure describes the reference models that are derived from RFC3985 to support the frame relay PW emulated services.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| CE1 | | | | | | | | CE2 |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | (PE1) (PE2) | |
Customer | | Customer Edge 1 | | Edge 2
| |
| |
Attachment Circuit (AC) Attachment Circuit (AC)
native frame relay service native frame relay service
Figure 1. PWE3 frame relay PVC interface reference configuration
Two mapping modes can be defined between frame relay VCs and pseudowires: The first one is called "one-to-one" mapping, because there is a one-to-one correspondence between a frame relay VC and one pseudowire. The second mapping is called "many-to-one" mapping or "port mode" because multiple frame relay VCs assigned to a port are mapped to one pseudowire. The "port mode" encapsulation is identical to High-Level Data Link Control (HDLC) pseudowire encapsulation, which is described in RFC4618.
Specification of Requirements
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 RFC 2119.
Below are the definitions for the terms used throughout the document. PWE3 definitions can be found in [RFC3916, RFC3985]. This section defines terms specific to frame relay.
- Forward direction
The forward direction is the direction taken by the frame being forwarded.
- Backward direction
In frame relay, it is the direction opposite to the direction taken by a frame being forwarded (see also forward direction).
Co-authors
The following are co-authors of this document:
Nasser El-Aawar Level 3 Communications, LLC Eric C. Rosen Cisco Systems Daniel Tappan Cisco Systems Thomas K. Johnson Litchfield Communications Kireeti Kompella Juniper Networks, Inc. Steve Vogelsang Laurel Networks, Inc. Vinai Sirkay Reliance Infocomm Ravi Bhat Nokia Nishit Vasavada Nokia Giles Heron Tellabs Dimitri Stratton Vlachos Mazu Networks,Inc. Chris Liljenstolpe Cable & Wireless Prayson Pate Overture Networks, Inc
Acronyms and Abbreviations
BECN Backward Explicit Congestion Notification CE Customer Edge C/R Command/Response DE Discard Eligibility DLCI Data Link Connection Identifier FCS Frame Check Sequence FECN Forward Explicit Congestion Notification FR Frame Relay LSP Label Switched Path LSR Label Switching Router MPLS Multiprotocol Label Switching MTU Maximum Transfer Unit NNI Network-Network Interface PE Provider Edge PSN Packet Switched Network PW Pseudowire PWE3 Pseudowire Emulation Edge to Edge POS Packet over SONET/SDH PVC Permanent Virtual Circuit QoS Quality of Service SVC Switched Virtual Circuit UNI User-Network Interface VC Virtual Circuit
Applicability Statement
Frame relay over PW service is not intended to emulate the traditional frame relay service perfectly, but it can be used for applications that need frame relay transport service.
The following are notable differences between traditional frame relay service and the protocol described in this document:
- Frame ordering can be preserved using the OPTIONAL sequence field
in the control word; however, implementations are not required to support this feature.
- The Quality of Service model for traditional frame relay can be
emulated; however, this is outside the scope of this document.
- A Frame relay port mode PW does not process any frame relay status
messages or alarms as described in [Q922] [Q933]
- The frame relay BECN and FECN bit are transparent to the MPLS
network and cannot reflect the status of the MPLS network.
- Support for frame relay SVC and Switched Permanent Virtual Circuit
(SPVC) is outside the scope of this document.
- Frame relay Local Management Interface (LMI) is terminated locally
in the PE connected to the frame relay attachment circuit.
- The support of PVC link integrity check is outside the scope of
this document.
General Encapsulation Method
The general frame relay pseudowire packet format for carrying frame relay information (user's payload and frame relay control information) between two PEs is shown in Figure 2.
+-------------------------------+
| |
| MPLS Transport header |
| (As required) |
+-------------------------------+
| Pseudowire (PW) Header |
+-------------------------------+
| Control Word |
+-------------------------------+
| FR Service |
| Payload |
+-------------------------------+
Figure 2. General format of frame relay encapsulation over PSN
The PW packet consists of the following fields: Control word and Payload, preceded by the MPLS Transport and pseudowire header. The meaning of the different fields is as follows:
-i. MPLS Transport header is specific to the MPLS network. This
header is used to switch the PW packet through the MPLS core.
-ii. PW header contains an identifier for multiplexing PWs within
an MPLS tunnel.
-iii. Control Word contains protocol control information for
providing a frame relay service. Its structure is provided in
the following sections.
-iv. The content of the frame relay service payload field depends
on the mapping mode. In general it contains the layer 2 frame
relay frame.
Frame Relay over MPLS PSN for the One-to-One Mode
MPLS PSN Tunnel and PW
MPLS label switched paths (LSPs) called "MPLS Tunnels" are used between PEs and are used within the MPLS core network to forward PW packets. An MPLS tunnel corresponds to "PSN Tunnel" of Figure 1.
Several PWs may be nested inside one MPLS tunnel. Each PW carries the traffic of a single frame relay VC. In this case, the PW header is an MPLS label called the PW label.
Packet Format over MPLS PSN
For the one-to-one mapping mode for frame relay over an MPLS network, the PW packet format is as shown in Figure 3.
+-------------------------------+ | MPLS Tunnel label(s) | n*4 octets (four octets per label) +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Control Word | | (See Figure 4) | 4 octets +-------------------------------+ | Payload | | (Frame relay frame | | information field) | n octets | | +-------------------------------+
Figure 3. Frame Relay over MPLS PSN Packet for the
One-to-One Mapping
The meaning of the different fields is as follows:
- MPLS Tunnel label(s)
The MPLS Tunnel label(s) corresponds to the MPLS transport header of Figure 2. The label(s) is/are used by MPLS LSRs to forward a PW packet from one PE to the other.
- PW Label
The PW label identifies one PW (i.e., one LSP) assigned to a frame relay VC in one direction. It corresponds to the PW header of Figure 2. Together the MPLS Tunnel label(s) and PW label form an MPLS label stack RFC3032.
- Control Word
The Control Word contains protocol control information. Its structure is shown in Figure 4.
- Payload
The payload field corresponds to X.36/X.76 frame relay frame information field with the following components removed: bit/byte stuffing, frame relay header, and FCS. It is RECOMMENDED to support a frame size of at least 1600 bytes. The maximum length of the payload field MUST be agreed upon by the two PEs. This can be achieved by using the MTU interface parameter when the PW is established. RFC4447
The Control Word
The control word defined below is REQUIRED for frame relay one-to-one mode. The control word carries certain frame relay specific information that is necessary to regenerate the frame relay frame on the egress PE. Additionally, the control word also carries a sequence number that can be used to preserve sequentiality when carrying frame relay over an MPLS network. Its structure is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|F|B|D|C|FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Control Word structure for the one-to-one mapping mode
The meaning of the Control Word fields (Figure 4) is as follows (see also [X36 and X76] for frame relay bits):
- Bits 0 to 3
In the above diagram, the first 4 bits MUST be set to 0 to indicate PW data.
- F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit.
- B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit.
- D (bit 6) FR DE bit (Discard Eligibility) bit.
- C (bit 7) FR frame C/R (Command/Response) bit.
- FRG (bits 8 and 9): These bits are defined by RFC4623.
- Length (bits 10 to 15)
If the PW traverses a network link that requires a minimum frame size (a notable example is Ethernet), padding is required to reach its minimum frame size. If the frame's length (defined as the length of the layer 2 payload plus the length of the control word) is less than 64 octets, the length field MUST be set to the PW payload length. Otherwise, the length field MUST be set to zero. The value of the length field, if non-zero, is used to remove the padding characters by the egress PE.
- Sequence number (Bit 16 to 31)
Sequence numbers provide one possible mechanism to ensure the ordered delivery of PW packets. The processing of the sequence number field is OPTIONAL. The sequence number space is a 16-bit unsigned circular space. The sequence number value 0 is used to indicate that the sequence number check algorithm is not used.
The Martini Legacy Mode Control Word
For backward compatibility to existing implementations, the following version of the control word is defined as the "martini mode CW" for frame relay.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|B|F|D|C|FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Control Word structure for the frame relay martini mode
Note that the "B" and "F" bits are reversed.
This control word format is used for PW type "Frame Relay DLCI ( Martini Mode )"
PW Packet Processing
Encapsulation of Frame Relay Frames
The encapsulation process of a frame relay frame is initiated when a PE receives a frame relay frame from one of its frame relay UNI or NNI [FRF1] [FRF2] interfaces. The PE generates the following fields
of the control word from the corresponding fields of the frame relay frame as follows:
- Command/Response (C/R or C) bit: The C bit is copied unchanged in
the PW Control Word.
- The DE bit of the frame relay frame is copied into the D bit field.
However, if the D bit is not already set, it MAY be set as a result of ingress frame policing. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1).
- The FECN bit of the frame relay frame is copied into the F bit
field. However, if the F bit is not already set, it MAY be set to reflect a congestion situation detected by the PE. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1)
- The BECN bit of the frame relay frame is copied into the B bit
field. However, if the B bit is not already set, it MAY be set to reflect a congestion situation detected by the PE. If it is not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1).
- If the PW packet length (defined as the length of the payload plus
the length of the control word) is less than 64 octets, the length field MUST be set to the packet's length. Otherwise, the length field MUST be set to zero.
- The sequence number field is processed if the PW uses sequence
numbers. RFC4385
- The payload of the PW packet is the contents of ITU-T
Recommendations X.36/X.76 [X36] [X76] frame relay frame information field stripped from any bit or byte stuffing.
Setting the Sequence Number
For a given PW and a pair of routers PE1 and PE2, if PE1 supports packet sequencing, then the procedures in RFC4385, Section 4.1, MUST be followed.
Decapsulation of PW Packets
When a PE receives a PW packet, it processes the different fields of the control word in order to decapsulate the frame relay frame for transmission to a CE on a frame relay UNI or NNI. The PE performs the following actions (not necessarily in the order shown):
- It generates the following frame relay frame header fields from the
corresponding fields of the PW packet.
- The C/R bit MUST be copied in the frame relay header.
- The D bit MUST be copied into the frame relay header DE bit.
- The F bit MUST be copied into the frame relay header FECN bit. If
the F bit is set to zero, the FECN bit may be set to one, depending on the congestion state of the PE device in the forward direction. Changing the state of this bit by a PE is OPTIONAL.
- The B bit MUST be copied into the frame relay header BECN bit. If
the B bit is set to zero, the BECN bit may be set to one, depending on the congestion state of the PE device in the backward direction. Changing the state of this bit by a PE is OPTIONAL.
- It processes the length and sequence field, the details of which
are in the following sub-sections.
- It copies the frame relay information field from the contents of
the PW packet payload after removing any padding.
Once the above fields of a FR frame have been processed, the standard HDLC operations are performed on the frame relay frame: the HDLC header is added, any bit or byte stuffing is added as required, and the FCS is also appended to the frame. The FR frame is then queued for transmission on the selected frame relay UNI or NNI interface.
Processing the Sequence Number
If a router PE2 supports received sequence number processing, then the procedures in RFC4385, Section 4.2, MUST be used.
Processing of the Length Field by the Receiver
Any padding octet, if present, in the payload field of a PW packet received MUST be removed before forwarding the data.
- If the Length field is set to zero, then there are no padding
octets following the payload field.
- Otherwise, if the payload is longer, then the length specified in
the control word padding characters are removed according to the length field.
MPLS Shim EXP Bit Values
If it is desired to carry Quality of Service information, the Quality of Service information SHOULD be represented in the Experimental Use Bits (EXP) field of the PW MPLS label RFC3032. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack SHOULD also carry the same value.
MPLS Shim S Bit Value
The ingress LSR, PE1, MUST set the S bit of the PW label to a value of 1 to denote that the PW label is at the bottom of the stack.
Control Plane Details for Frame Relay Service
The PE MUST provide frame relay PVC status signaling to the frame relay network. If the PE detects a service-affecting condition for a particular DLCI, as defined in [Q933] Q.933, Annex A.5, sited in IA FRF1.1, the PE MUST communicate to the remote PE the status of the PW that corresponds to the frame relay DLCI status. The Egress PE SHOULD generate the corresponding errors and alarms as defined in [Q922] [Q933] on the egress Frame relay PVC.
There are two frame relay flags to control word bit mappings described below. The legacy bit ordering scheme will be used for a PW of type 0x0001, "Frame Relay DLCI (Martini Mode)", and the new bit ordering scheme will be used for a PW of type 0x0019, "Frame Relay DLCI". The IANA allocation registry of "Pseudowire Type" is defined in RFC4446 along with initial allocated values.
Frame Relay Specific Interface Parameter Sub-TLV
A separate document, RFC4447, describes the PW control and maintenance protocol in detail, including generic interface parameter sub-TLVs. The interface parameter information, when applicable, MUST be used to validate that the PEs and the ingress and egress ports at the edges of the circuit have the necessary capabilities to interoperate with each other. The Interface parameter TLV is defined in RFC4447, and the IANA registry with initial values for interface parameter sub-TLV types is defined in RFC4446, but the frame relay specific interface parameter sub-TLV types are specified as follows:
- 0x08 Frame Relay Header Length Sub-TLV
An optional 16-bit value indicating the length of the FR Header, expressed in octets. This OPTIONAL interface parameter Sub-TLV can have value of 2, 3, or 4, the default being 2. If this Sub-TLV is not present, the default value of 2 is assumed.
Frame Relay Port Mode
The frame relay port mode PW shares the same encapsulation as the HDLC PW and is described in the respective document. RFC4618
Congestion Control
As explained in RFC3985, the PSN carrying the PW may be subject to congestion, the characteristics of which depend on PSN type, network architecture, configuration, and loading. During congestion, the PSN may exhibit packet loss that will impact the service carried by the frame relay PW. In addition, since frame relay PWs carry a variety of services across the PSN, including but not restricted to TCP/IP, they may or may not behave in a TCP-friendly manner prescribed by RFC2914. In the presence of services that reduce transmission rate, frame relay PWs may thus consume more than their fair share and in that case SHOULD be halted.
Whenever possible, frame relay PWs should be run over traffic- engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the frame relay PW's effects from neighboring streams.
Note that when transporting frame relay, DiffServ-enabled domains may use AF (Assured Forwarding) and/or DF (Default Forwarding) instead of EF, in order to place less burden on the network and to gain additional statistical multiplexing advantage. In particular, if the Committed Information Rate (CIR) of a frame relay VC is zero, then it is equivalent to a best-effort UDP over IP stream regarding congestion: the network is free to drop frames as necessary. In this case, the "DF" Per Hop Behavior (PHB) would be appropriate in a diff-serv-TE domain. Alternatively, if the CIR of a frame relay VC is nonzero and the DE bit is zero in the FR header, then "AF31" would be appropriate to be used, and if the CIR of a frame relay VC is nonzero but the DE bit is on, then "AF32" would be appropriate RFC3270.
The PEs SHOULD monitor for congestion (by using explicit congestion notification, [VCCV], or by measuring packet loss) in order to ensure that the service using the frame relay PW may be maintained. When a
PE detects significant congestion while receiving the PW PDUs, the BECN bits of the frame relay frame transmitted on the same PW SHOULD be set to notify the remote PE and the remote frame relay switch of the congestion situation. In addition, the FECN bits SHOULD be set in the FR frames sent out the attachment circuit, to give the FR DTE a chance to adjust its transport layer advertised window, if possible.
If the PW has been set up using the protocol defined in RFC4447, then procedures specified in RFC4447 for status notification can be used to disable packet transmission on the ingress PE from the egress PE. The PW may be restarted by manual intervention, or by automatic means after an appropriate waiting time.
10. Security Considerations
PWE3 provides no means of protecting the contents or delivery of the PW packets on behalf of the native service. PWE3 may, however, leverage security mechanisms provided by the MPLS Tunnel Layer. A more detailed discussion of PW security is given in [RFC3985, RFC4447, RFC3916].
11. Normative References
RFC4447 Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
RFC4385 Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
RFC3032 Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
RFC4446 Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
RFC4618 Martini, L., Rosen, E., Heron, G., and A. Malis,
"Encapsulation Methods for Transport of Point to Point
Protocol/High-Level Data Link Control (PPP/HDLC) over
Multiprotocol Label Switching (MPLS) Networks", RFC 4618,
September 2006.
RFC4623 Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
12. Informative References
RFC3985 Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[VCCV] Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection
Verification (VCCV)", Work in Progress, October 2005.
[ATM] Martini, L., et al., "Encapsulation Methods for Transport
of ATM Over MPLS Networks", Work in Progress, April 2005.
RFC4448 Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement,
Frame Relay Forum, April 2000.
[FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement,
Frame Relay Forum, April 2002
RFC3916 Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[X36] ITU-T Recommendation X.36, Interface between a DTE and DCE
for public data networks providing frame relay, Geneva,
2000.
[X76] ITU-T Recommendation X.76, Network-to-network interface
between public data networks providing frame relay
services, Geneva,2000
[Q922] ITU-T Recommendation Q.922 Specification for Frame Mode
Basic call control, ITU Geneva 1995
[Q933] ITU-T Recommendation Q.933 Specification for Frame Mode
Basic call control, ITU Geneva 2003
RFC2914 Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
RFC3270 Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
Contributing Author Information
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
EMail: [email protected]
Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK
EMail: [email protected]
Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140
EMail: [email protected]
Chris Liljenstolpe Alcatel 11600 Sallie Mae Dr. 9th Floor Reston, VA 20193
EMail: [email protected]
Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021
EMail: [email protected]
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
EMail: [email protected]
Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
EMail: [email protected]
Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560
EMail: [email protected]
David Sinicrope Ericsson IPI
EMail: [email protected]
Ravi Bhat Nokia
EMail: [email protected]
Nishit Vasavada Nokia
EMail: [email protected]
Steve Vogelsang ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205
EMail: [email protected]
Vinai Sirkay Redback Networks 300 Holger Way, San Jose, CA 95134
EMail: [email protected]
Authors' Addresses
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
EMail: [email protected]
Claude Kawa OZ Communications Windsor Station 1100, de la Gauchetie`re St West Montreal QC Canada H3B 2S2
EMail: [email protected]
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
EMail: [email protected]
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in 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 [email protected].
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
