RFC 4816

Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service

📅 published February 2007, from ietf

RFC 4816 💖 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service

Network Working Group 🌸 this one is from February 2007 and it's a Standards Track doc 🧚

The authors are A. Malis (Verizon), L. Martini (Cisco Systems), J. Brayley (ECI Telecom), and T. Walsh (Juniper Networks). Their contact details are in the Author's Addresses section below 💅

Status of This Memo ✨

This is an Internet standards track protocol doc for the Internet community 🦋 It's open for discussion and suggestions for improvements, so if you spot something, speak up. To check where this protocol stands, look at the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The IETF Trust (2007).

Abstract 💜

Okay so this doc describes a transparent cell transport service that uses 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 lets you move ATM services over a PSN without setting up the ATM subscriber or customer edge (CE) devices 🫶 The ATM CEs think they're directly connected by a Time Division Multiplexer (TDM) leased line, so they literally can't tell the difference 😭 It's most likely to live inside an ATM service provider's network, where it connects existing ATM switches over a higher-speed PSN, or gives ATM "backhaul" services for remote access to existing ATM networks 💅

1.1. Specification of Requirements 🍓

Here's the deal with the requirement words: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [1] 🧠

2. Transparent Cell Transport Definition 🦋

The transparent port service is basically a natural match for the "N-to-one" Virtual Circuit Connection (VCC) cell transport mode for PWE3 ATM encapsulation from [2] 💖 It MUST be used with pseudowires of type 0x0003, which is "ATM transparent cell transport" [4] ✨

The ATM transparent port service emulates connectivity between two remote ATM ports 🌸 It's super useful when you want to connect two CEs without any processing or switching at the Virtual Path Connection (VPC) or VCC layer 💅 The ingress PE throws away any idle/unassigned cells it gets from the ingress ATM port, and maps all the other cells it receives onto 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 out the egress ATM port 🧚 So the transparent port service appears to emulate an ATM transmission convergence layer connection between two ports 👑 Plus, since the ingress PE discards idle/unassigned cells, this service gets statistical multiplexing bandwidth savings 🤑

According to [2], cell concatenation MAY be used for transparent cell-relay transport to save PSN bandwidth 🫧 If you use it, it MUST be agreed between the ingress and egress PEs 🤝 Specifically, if the Pseudo Wire was set up with 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]) that came in the Label Mapping message for the Pseudo Wire 😤 And if the egress PE left this parameter out, the ingress PE MUST NOT use cell concatenation at all 🙈

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 don't generate any OAM cells. Instead, they bring down the ATM interfaces to the CEs (e.g., generating LOS on the ATM port), just like it's a transmission layer failure 💀

Similarly, ATM Integrated Local Management Interface (ILMI) signaling from the CEs, if there's any, MUST be transported transparently, and the PEs do not act on it 🌈 However, the PEs must act on a physical interface failure, either by withdrawing the PW labels or by using pseudowire status signaling to show the interface failure 🚨 The procedures for both options are described in [3] 📖

3. Security Considerations 🔐

This document doesn't introduce any new security considerations beyond the ones in [2] and [3]. It defines an application that uses the encapsulation specified in [2], and it does not specify the protocols used to carry the encapsulated packets across the PSN. Each of those protocols may have its own set of security issues, but the application defined here doesn't change them. 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 is about an application of the "N-to-one" VCC cell transport mode for PWE3 ATM encapsulation from [2], the congestion control considerations are identical to the ones discussed in section 15 of [2] 🫶 The PWE3 Working Group is also doing extra work on ATM-related congestion issues 👀 So implementers should expect an RFC to come out 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.

Acknowledgments 🙏

The authors want to thank the members of the PWE3 working group for their help with this doc 🫶 They also shout out 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

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions in BCP 78. Except as set out there, the authors keep all their rights 💅

The doc and the info in it are provided on an "AS IS" basis, and the disclaimer below is the official legal wording:

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 doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover this technology are valid or in scope, or whether a license under those rights is available. It also doesn't claim to have done any independent search for such rights 🫠 You can find the procedures for rights in RFC documents in BCP 78 and BCP 79 📜

IPR disclosures made to the IETF Secretariat, and any assurances of licenses or the results of attempts to get a general license for implementers or users, are available from the IETF online IPR repository at http://www.ietf.org/ipr 📬

The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 💖

📦 where this page comes from