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.
7.6.1. Processing the Sequence Number
If a router PE2 supports received sequence number processing, then
the procedures in [RFC4385], Section 4.2, MUST be used.
7.6.2. 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.
7.7. 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.
7.8. 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.
7.9. 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.
7.9.1. 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.
8. 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]
9. 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: kireeti@juniper.net
Giles Heron
Tellabs
Abbey Place
24-28 Easton Street
High Wycombe
Bucks
HP11 1NT
UK
EMail: giles.heron@tellabs.com
Rao Cherukuri
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Dimitri Stratton Vlachos
Mazu Networks, Inc.
125 Cambridgepark Drive
Cambridge, MA 02140
EMail: d@mazunetworks.com
Chris Liljenstolpe
Alcatel
11600 Sallie Mae Dr.
9th Floor
Reston, VA 20193
EMail: chris.liljenstolpe@alcatel.com
Nasser El-Aawar
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
EMail: nna@level3.net
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Dan Tappan
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: tappan@cisco.com
Prayson Pate
Overture Networks, Inc.
507 Airport Boulevard
Morrisville, NC, USA 27560
EMail: prayson.pate@overturenetworks.com
David Sinicrope
Ericsson IPI
EMail: david.sinicrope@ericsson.com
Ravi Bhat
Nokia
EMail: ravi.bhat@nokia.com
Nishit Vasavada
Nokia
EMail: nishit.vasavada@nokia.com
Steve Vogelsang
ECI Telecom
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: stephen.vogelsang@ecitele.com
Vinai Sirkay
Redback Networks
300 Holger Way,
San Jose, CA 95134
EMail: sirkay@technologist.com
Authors’ Addresses
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
Claude Kawa
OZ Communications
Windsor Station
1100, de la Gauchetie`re St West
Montreal QC Canada
H3B 2S2
EMail: claude.kawa@oz.com
Andrew G. Malis
Tellabs
1415 West Diehl Road
Naperville, IL 60563
EMail: Andy.Malis@tellabs.com
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
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).