FR VCs assigned to a port as an aggregate.
FR port mode provides transport between two PEs of a complete FR
frame using the same encapsulation as described above for HDLC mode.
Although frame relay port mode shares the same encapsulation as HDLC
mode, a different PW type is allocated in [RFC4446]: 0x000F Frame-
Relay Port mode.
All other aspects of this PW type are identical to the HDLC PW
encapsulation described above.
5.3. PPP
PPP mode provides point-to-point transport of PPP-encapsulated
traffic, as specified in [RFC1661]. The PPP PDU is transported in
its entirety, including the protocol field (whether compressed using
Protocol Field Compression or not), but excluding any media-specific
framing information, such as HDLC address and control fields or FCS.
If the OPTIONAL control word is used, then the flag bits in the
control word are not used and MUST be set to 0 for transmitting and
MUST be ignored upon receipt.
When the PE detects a status change in the attachment circuit (AC)
status, such as an attachment circuit physical link failure, or if
the AC is administratively disabled, the PE MUST send the appropriate
PW status notification message that corresponds to the PPP AC status.
Note that PPP negotiation status is transparent to the PW and MUST
NOT be communicated to the remote MPLS PE. In a similar manner, the
local PW status MUST also be reflected in a respective PW status
notification message, as described in [RFC4447].
A PW of type 0x0007 "PPP" will be used to transport PPP packets.
The IANA allocation registry of "Pseudowire Type" is defined in the
IANA allocation document for PWs [RFC4446] along with initial
allocated values.
6. Using an MPLS Label as the Demultiplexer Field
To use an MPLS label as the demultiplexer field, a 32-bit label stack
entry [RFC3032] is simply prepended to the emulated PW encapsulation
and thus appears as the bottom label of an MPLS label stack. This
label may be called the "PW label". The particular emulated PW
identified by a particular label value must be agreed by the ingress
and egress LSRs, either by signaling (e.g., via the methods of
[RFC4447]) or by configuration. Other fields of the label stack
entry are set as described below.
6.1. 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 EXP field of the
PW label. If more than one MPLS label is imposed by the ingress LSR,
the EXP field of any labels higher in the stack MUST also carry the
same value.
6.2. 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. Congestion Control
As explained in [RFC3985], the PSN carrying the PW may be subject to
congestion, the characteristics of which are dependent upon PSN type,
network architecture, configuration, and loading. During congestion,
the PSN may exhibit packet loss that will impact the service carried
by the PPP/HLDC PW. In addition, since PPP/HDLC PWs carry an
unspecified type of services across the PSN, they cannot behave in a
TCP-friendly manner prescribed by [RFC2914]. In the presence of
services that reduce transmission rate, PPP/HDLC PWs will thus
consume more than their fair share and SHOULD be halted.
Whenever possible, PPP/HDLC 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 PPP/HDLC PW’s effects
from neighboring streams.
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 PPP/HDLC PW may be maintained. When
significant congestion is detected, the PPP/HDLC PW SHOULD be
administratively disabled. 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.
8. IANA Considerations
This document has no new IANA Actions. All necessary IANA actions
have already been included in [RFC4446].
9. Security Considerations
The PPP and HDLC pseudowire type is subject to all the general
security considerations discussed in [RFC3985][RFC4447]. This
document specifies only encapsulations, and not the protocols that
may be used to carry the encapsulated packets across the MPLS
network. Each such protocol may have its own set of security issues,
but those issues are not affected by the encapsulations specified
herein.
10. Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[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.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[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.
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed.,
"Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks", RFC
4619, September 2006.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-
to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006.
11. Informative References
[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.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "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.
Contributing Author Information
Yeongil Seo
463-1 KT Technology Lab
Jeonmin-dong Yusung-gu
Daegeon, Korea
EMail: syi1@kt.co.kr
Toby Smith
Laurel Networks, Inc.
Omega Corporate Center
1300 Omega Drive
Pittsburgh, PA 15205
EMail: tob@laurelnetworks.com
Authors’ Addresses
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
Giles Heron
Tellabs
Abbey Place
24-28 Easton Street
High Wycombe
Bucks
HP11 1NT
UK
EMail: giles.heron@tellabs.com
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.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).