summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4816.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4816.txt')
-rw-r--r--doc/rfc/rfc4816.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc4816.txt b/doc/rfc/rfc4816.txt
new file mode 100644
index 0000000..b7ddae7
--- /dev/null
+++ b/doc/rfc/rfc4816.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group A. Malis
+Request for Comments: 4816 Verizon
+Category: Standards Track L. Martini
+ Cisco Systems
+ J. Brayley
+ ECI Telecom
+ T. Walsh
+ Juniper Networks
+ February 2007
+
+
+ Pseudowire Emulation Edge-to-Edge (PWE3)
+ Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service
+
+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 IETF Trust (2007).
+
+Abstract
+
+ The document describes a transparent cell transport service that
+ makes use of the "N-to-one" cell relay mode for Pseudowire Emulation
+ Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell
+ encapsulation.
+
+1. Introduction
+
+ This transparent cell transport service allows migration of ATM
+ services to a PSN without having to provision the ATM subscriber or
+ customer edge (CE) devices. The ATM CEs will view the ATM
+ transparent cell transport service as if they were directly connected
+ via a Time Division Multiplexer (TDM) leased line. This service is
+ most likely to be used as an internal function in an ATM service
+ provider's network as a way to connect existing ATM switches via a
+ higher-speed PSN, or to provide ATM "backhaul" services for remote
+ access to existing ATM networks.
+
+
+
+
+
+
+
+Malis, et al. Standards Track [Page 1]
+
+RFC 4816 PWE3 ATM Transparent Cell Transport Service February 2007
+
+
+1.1. 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 [1].
+
+2. Transparent Cell Transport Definition
+
+ The transparent port service is a natural application of the "N-to-
+ one" Virtual Circuit Connection (VCC) cell transport mode for PWE3
+ ATM encapsulation described in [2], and MUST be used with pseudowires
+ of type 0x0003, "ATM transparent cell transport" [4].
+
+ The ATM transparent port service emulates connectivity between two
+ remote ATM ports. This service is useful when one desires to connect
+ two CEs without processing or switching at the Virtual Path
+ Connection (VPC) or VCC layer. The ingress PE discards any
+ idle/unassigned cells received from the ingress ATM port, and maps
+ all other received cells to a single pseudowire.
+
+ The egress PE does not change the Virtual Path Identifier (VPI),
+ Virtual Circuit Identifier (VCI), Payload Type Identifier (PTI), or
+ Cell Loss Priority (CLP) bits when it sends these cells on the egress
+ ATM port. Therefore, the transparent port service appears to emulate
+ an ATM transmission convergence layer connection between two ports.
+ However, since the ingress PE discards idle/unassigned cells, this
+ service benefits from statistical multiplexing bandwidth savings.
+
+ In accordance with [2], cell concatenation MAY be used for
+ transparent cell-relay transport in order to save the PSN bandwidth.
+ If used, it MUST be agreed between the ingress and egress PEs. In
+ particular, if the Pseudo Wire has been set up using the PWE3 control
+ protocol [3], the ingress PE MUST NOT exceed the value of the
+ "Maximum Number of concatenated ATM cells" Pseudowire Interface
+ Parameter Sub-TLV (Interface Parameter ID = 0x02 [4]) received in the
+ Label Mapping message for the Pseudo Wire, and MUST NOT use cell
+ concatenation if this parameter has been omitted by the egress PE.
+
+ ATM Operations and Management (OAM) cells MUST be transported
+ transparently, and the PEs do not act on them. If the PEs detect a
+ PSN or pseudowire failure between them, they do not generate any OAM
+ cells, but rather bring down the ATM interfaces to the CEs (e.g.,
+ generating LOS on the ATM port), just as if it were a transmission
+ layer failure.
+
+
+
+
+
+
+
+Malis, et al. Standards Track [Page 2]
+
+RFC 4816 PWE3 ATM Transparent Cell Transport Service February 2007
+
+
+ Similarly, ATM Integrated Local Management Interface (ILMI) signaling
+ from the CEs, if any, MUST be transported transparently, and the PEs
+ do not act on it. However, the PEs must act on physical interface
+ failure by either withdrawing the PW labels or by using pseudowire
+ status signaling to indicate the interface failure. The procedures
+ for both alternatives are described in [3].
+
+3. Security Considerations
+
+ This document does not introduce any new security considerations
+ beyond those in [2] and [3]. This document defines an application
+ that utilizes the encapsulation specified in [2], and does not
+ specify the protocols used to carry the encapsulated packets across
+ the PSN. Each such protocol may have its own set of security issues,
+ but those issues are not affected by the application specified
+ herein. Note that the security of the transported ATM service will
+ only be as good as the security of the PSN. This level of security
+ might be less rigorous than a native ATM service.
+
+4. Congestion Control
+
+ Since this document discusses an application of the "N-to-one" VCC
+ cell transport mode for PWE3 ATM encapsulation described in [2], the
+ congestion control considerations are identical to those discussed in
+ section 15 of [2]. The PWE3 Working Group is also undertaking
+ additional work on ATM-related congestion issues, and implementers
+ should anticipate that an RFC will be published describing additional
+ congestion control techniques that should be applied to ATM emulation
+ over pseudowires.
+
+5. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J.,
+ and G. Koleyni, "Encapsulation Methods for Transport of
+ Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717,
+ December 2006.
+
+ [3] 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.
+
+ [4] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+ Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+
+
+
+
+Malis, et al. Standards Track [Page 3]
+
+RFC 4816 PWE3 ATM Transparent Cell Transport Service February 2007
+
+
+Acknowledgments
+
+ The authors would like to thank the members of the PWE3 working group
+ for their assistance on this document, and Sasha Vainshtein of Axerra
+ in particular for his comments and suggestions.
+
+Author's Addresses
+
+ Andrew G. Malis
+ Verizon Communications
+ 40 Sylvan Road
+ Waltham, MA
+
+ EMail: andrew.g.malis@verizon.com
+
+
+ Luca Martini
+ Cisco Systems, Inc.
+ 9155 East Nichols Avenue, Suite 400
+ Englewood, CO, 80112
+
+ EMail: lmartini@cisco.com
+
+
+ Jeremy Brayley
+ ECI Telecom
+ Omega Corporate Center
+ 1300 Omega Drive
+ Pittsburgh, PA 15205
+
+ EMail: jeremy.brayley@ecitele.com
+
+
+ Tom Walsh
+ Juniper Networks
+ 1194 N Mathilda Ave
+ Sunnyvale, CA 94089
+
+ EMail: twalsh@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+Malis, et al. Standards Track [Page 4]
+
+RFC 4816 PWE3 ATM Transparent Cell Transport Service February 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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, THE IETF TRUST 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 currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Malis, et al. Standards Track [Page 5]
+