Network Working Group George Swallow
Internet Draft Cisco Systems, Inc.
Category: Standards Track
Expiration Date: August 2005
Mickey Spiegel
Cisco Systems, Inc.
February 2005
Soft Permanent Virtual Circuit Interworking between PWE3 and ATM
draft-swallow-pwe3-spvc-iw-02.txt
Status of this Memo
By submitting this Internet-Draft, the authors certify that any
applicable patent or other IPR claims of which we are aware have been
disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 5 of RFC3667. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines interworking between Private Network Node
Interface (PNNI) SPVC signaling and the Label Distribution Protocol
Swallow & Spiegel Standards Track [Page 1]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
[LDP] as extended by [PWE3-CP] and [L2VPN-SIG].
Contents
1 Introduction .............................................. 3
1.1 Conventions ............................................... 3
1.2 Terminology ............................................... 3
2 Problem Statement ......................................... 4
2.1 Reference Network Diagram ................................. 5
3 Requirements .............................................. 5
3.1 Configuration ............................................. 6
3.2 Redundant ATM/PSN Interfaces .............................. 6
3.3 Re-assembly ............................................... 6
3.4 No Change to Existing ATM Signaling Protocols ............. 6
3.5 Frame Relay and ATM Circuits at the MPLS Network Edge ..... 6
4 Non-Requirements .......................................... 7
4.1 Frame Relay / ATM Interworking ............................ 7
5 Background on identifiers ................................. 7
5.1 Pseudowire Identifiers .................................... 7
5.2 ATM SPVC Identifiers ...................................... 8
6 Proposed Solution ......................................... 9
6.1 PSN / ATM Interface ....................................... 9
6.2 Signaling ................................................. 9
6.3 Mapping Identifiers ....................................... 10
6.3.1 Mapping Addresses ......................................... 10
6.3.2 Mapping Port and SPVC IEs to AIs .......................... 11
6.4 Configuration ............................................. 12
6.5 Procedures ................................................ 12
6.5.1 Procedures within the ATM Network ......................... 12
6.5.2 Procedures for the ME ..................................... 13
6.5.3 Procedures for the PME .................................... 13
6.5.4 Call Completion ........................................... 14
6.6 Handling Re-assembly ...................................... 14
7 Issues .................................................... 14
8 Security Considerations ................................... 15
9 Acknowledgments ........................................... 15
10 References ................................................ 15
10.1 Normative References ...................................... 15
10.2 Informative References .................................... 15
/Users/swallow/ietf/pwe3/pwe/atmpwe050220:679: warning: escape character ignored before `'
11 Authors' Addresses ........................................ 16
12 Full Copyright and Intellectual Property Statements ....... 16
Swallow & Spiegel Standards Track [Page 2]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
1. Introduction
In current ATM deployments, Soft Permanent Virtual Connections
(SPVCs) are used to provision both Asynchronous Transfer Mode (ATM)
Permanent Virtual Channel Connections (PVCC) and Permanent Virtual
Path Connections (PVPC) and Frame Relay (FR) PVCCs.
Pseudowires over Multiprotocol Label Switching (MPLS) and L2TPv3 PSNs
are current being introduced as backbone technologies to carry these
same services. Mechanisms are being developed to enable a flexible
provisioning model which incorporates elements of the SPVC model in
that configuration of the end service exists only at the end-points.
These mechanisms are described in [PWE3-CP] and [L2VPN-SIG].
As services are migrated from ATM to PSNs, any reasonable deployment
scenario mandates that there be a period of time (possibly protracted
or permanent) in which services will need to be established and main-
tained between end-users where one end of a circuit is attached to an
ATM network and the other end is attached to a PSN.
1.1. Conventions
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 [KEYWORDS].
1.2. Terminology
PAE Provider ATM Edge, a customer facing node which is part of
the ATM network
AE ATM Edge, a node of the ATM network which is attached to a
node of the MPLS/IP network
PSN Packet Switched Network
PME Provider MPLS/IP Edge, a customer facing node which is part
of the MPLS/IP PSN
ME MPLS/IP Edge, a node of the MPLS/IP PSN which is attached to
a node of the ATM network
AI Attachment Identifier
AGI Attachment Group Identifier
Swallow & Spiegel Standards Track [Page 3]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
AII Attachment Individual Identifier
SAI Source Attachment Identifier
TAI Target Attachment Identifier
SAII Source Attachment Individual Identifier
TAII Target Attachment Individual Identifier
PNNI Private Network-Network Interface
UNI User Network Interface
AINI ATM Inter-Network Interface
PVCC Permanent Virtual Channel Connection
PVPC Permanent Virtual Path Connection
SPVC Soft Permanent Virtual Connection
IE Information Element
2. Problem Statement
To facilitate the migration of ATM and Frame Relay SPVCs to a PSN
carrying pseudowires, a means of interoperating ATM and LDP signaling
needs to be defined. Further this interoperation must preserve the
essential reasons for using SPVCs, namely, keeping configuration lim-
ited to the edge nodes supporting a particular connection and allow-
ing the network to be able to recover in the event of the failure of
any facility between those two edge nodes.
It is also useful to perform reassembly of AAL5 frames of Frame Relay
connections at the boundary between the ATM network and the PSN.
This serves to reduce dataplane protocol overhead in the PSN.
Finally, any solution must not preclude any existing services. In
particular, Frame Relay to ATM interworking is recognized to be in
wide use.
Swallow & Spiegel Standards Track [Page 4]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
2.1. Reference Network Diagram
The diagram below shows an ATM network interfaced to a PSN. A soft
PVC is to be set up between the two customer facing edge nodes, PAE,
and PME. Two interconnections are shown, to indicate that the con-
nection must be routable over either interconnection in the event of
the failure of the preferred interconnection. The 'M' (for MPLS/IP
PSN) was chosen over 'P' (for PSN) to allow 'P' to stand for
provider.
_______ _______
/ % / %
/ % +-----+ +-----+ / %
/ % | | | | / %
| |==| AE1 |==| ME1 |==| |
+-----+ | | | | | | | | +-----+
| | | ATM | +-----+ +-----+ | MPLS/IP | | |
| PAE |==| | | PSN |==| PME |
| | | | +-----+ +-----+ | | | |
+-----+ | | | | | | | | +-----+
| |==| AE2 |==| ME2 |==| |
% / | | | | % /
% / +-----+ +-----+ % /
%_______/ %_______/
Key:
All node acronyms are composed of the following
letters
P - Provider
M - MPLS/IP PSN
A - ATM
E - Edge
Figure 1: Reference Network
3. Requirements
The purpose of Soft Permanent Virtual Connections is two-fold. First
they confine circuit specific configuration to the edge nodes where
the user access circuits are terminated. Second they allow the net-
work to automatically reroute / re-establish the circuit when fail-
ures are encountered. The requirements for this solution follow
directly from this as well as some of the common uses of SPVCs.
Swallow & Spiegel Standards Track [Page 5]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
3.1. Configuration
All per circuit configuration must be limited to the edge nodes. In
particular the solution must not necessitate any per circuit configu-
ration on the nodes that support the ATM/PSN interface.
3.2. Redundant ATM/PSN Interfaces
The solution must support multiple inter-connections between the ATM
network and the PSN. Upon failure of an ATM/PSN interface, it must
be possible to re-route the SPVCs that had been traversing that
interface over other ATM/PSN interfaces.
3.3. Re-assembly
It must be possible to locate the AAL5 re-assembly at the ME. That
is, a ME by default will perform AAL5 re-assembly for Frame Relay
SPVCs. The ME's ATM/PSN interface may be configured to not perform
re-assembly and leave the job to the target PME, when the target PME
supports AAL5 re-assembly for Frame Relay circuits. No per circuit
selection need be supported.
3.4. No Change to Existing ATM Signaling Protocols
It is highly desirable that no changes be required to existing ATM
signaling protocols.
3.5. Frame Relay and ATM Circuits at the MPLS Network Edge
The solution must support both ATM and Frame Relay circuits at the
Provider MPLS Edge. For the case of ATM at the PME and Frame Relay
at the PAE, Frame Relay to ATM interworking is the responsibility of
the ATM network. For the case of Frame Relay at both the PME and the
PAE, FRF5 or FRF8.1 Frame Relay to ATM interworking capability is
required at the PME (to be specific, Frame Relay to AAL5 SDU Frame
encapsulation over PW) and is optional at the ME (Frame Relay over
Pseudo Wire to ATM). For the case of Frame Relay at the PME and ATM
at the PAE, Frame Relay to ATM interworking capability is required at
the PME and is optional at the ME.
Swallow & Spiegel Standards Track [Page 6]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
4. Non-Requirements
4.1. Frame Relay / ATM Interworking
While Frame Relay to ATM interworking is recognized as an important
and pervasive service, such a service is deemed to be beyond the
scope of this document. This is not to imply that such a service
cannot be supported by the means specified herein. It merely implies
that when Frame Relay to ATM interworking is required in the PSN net-
work, the interworking function (IWF) is located (and configured) at
the PME.
5. Background on identifiers
5.1. Pseudowire Identifiers
Pseudowires serve to connect a pair of attachment circuits (ACs). In
the context of this document these ACs are either Frame Relay DLCIs
or ATM VPI/VCIs. An AC is identified by an Attachment Identifier
(AI) and the IP address of the egress node. AIs are defined in [1].
An AI is a logical reference for both the physical/logical port as
well as the virtual circuit. That is an AC is fully identified by a
node-ID (IP address) and an AI.
The AI has further structure to designate groups of identifiers and
individual identifiers within a group, these are called attachment
group identifiers (AGI) and attachment individual identifiers (AII),
respectively. When pairs of AIs are used in signaling, they are fur-
ther designated by their role in the call, with the operative terms
being source and target of the call. Thus we also have the terminol-
ogy, source attachment identifier (SAI), source attachment individual
identifier (SAII), target attachment identifier (TAI), and target
attachment individual identifier (TAII). The source and target desig-
nations are only relevant from the perspective of the pseudowire con-
trol protocol. For example, a node receiving an LDP label mapping
message from a remote node will swap the SAI and TAI values when it
sends a label mapping message in the reverse direction back to the
originating node.
Attachment Identifiers (AIs) are carried in the Generalized ID FEC
Element of LDP. Each AI encoded as two fields, the Attachment Group
Identifier (AGI) and an Attachment Individual Identifier (AII), each
encoded using a type-length-value (TLV) format as defined in Section
5.2.2/[PWE3-CP]. In particular:
"Note that the interpretation of a particular field as AGI, SAII, or
Swallow & Spiegel Standards Track [Page 7]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
TAII depends on the order of its occurrence. The type field identi-
fies the type of the AGI, SAII, or TAII.
The rules for constructing the AGI and AII are left to the specifica-
tion of applications and/or models."
5.2. ATM SPVC Identifiers
In ATM, the identifying information of the attachment circuit at the
destination interface consists of an ATM End-System Address (AESA)
and the DLCI or VPI/VCI. The AESA identifies both the destination
node and port where the end-user is attached. The DLCI or VPI/VCI
are signaled in the Called party SPVC IE and are carried as literal
values. The Called party SPVC IE has two formats depending on
whether the service being signaled is a Frame Relay SPVC or an ATM
SPVC. Furthermore, ATM SPVCCs and ATM SPVPCs are distinguished
through the bearer class codepoint in the Broadband bearer capability
IE.
AESAs are based on the NSAP address format. Figure 2 shows the
generic format.
|--AFI (Authority & Format Identifier)
| Selector
| |--IDP (Initial Domain Part) |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | H O - D S P | E S I |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HO-DSP High Order Domain Specific Part
ESI End System Identifier
Figure 2: Generic AESA Format
Although many formats are permitted within AESAs, all ATM Forum
defined formats include a six byte End System Identifier or ESI. The
ESI's role is to identify a host. Typically, the first 13 bytes of
the AESA are common for all end systems attached to an ATM node.
This is the default behavior in PNNI. In this case, the ESI is used
to differentiate between end systems attached to the same switch.
From the point of view of the egress ATM switch, the ESI maps to a
physical or logical port.
Swallow & Spiegel Standards Track [Page 8]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
Thus common practice is to use the ESI to carry the port information.
6. Proposed Solution
6.1. PSN / ATM Interface
The interface between the ATM network and the PSN can be any of the
following:
ATM Forum User Network Interface (UNI)
ITU-T User Network Interface (UNI)
Private Network-Network Interface (PNNI)
ATM Inter-Network Interface (AINI)
In the case of the UNI, there must be extensions to support the
Called party soft PVPC or PVCC IE defined in [PNNI]. (In this docu-
ment we refer to the Called party soft PVPC or PVCC IE as simply the
SPVC IE.) There may be extensions to support:
o the Calling party soft PVPC or PVCC IE,
o signaled VPs, using the "transparent VP service" codepoint for
the bearer class in the Broadband bearer capability IE,
o crankback indication by setting the cause location in the Cause
IE to a value other than "user", and
o frame discard indication using either the Frame Discard bits
or the ATM adaptation layer parameters IE.
[Note: while the details of various versions of ATM signaling and the
support for particular IEs is a subject for other Fori and thus
beyond the scope of the WG (and IETF), an informative appendix
appropriate references will be added if the WG so desires.]
6.2. Signaling
In ATM soft PVCs are statically defined across the UNI interfaces,
but are signaled across the ATM network using PNNI signaling. For
the signaling part, one edge node is configured to be active for the
SPVC and the other is defined to be passive. That is, one end always
initiates the call. ATM signaling creates a bidirectional circuit in
a single pass. Bandwidth parameters for each direction of the cir-
cuit are carried in the setup message.
Swallow & Spiegel Standards Track [Page 9]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
A paradigm analogous to the active/passive roles in SPVC setup above
for pseudowires is known as single sided provisioning. These proce-
dures are defined in draft-rosen-ppvpn-l2-signaling-03.txt [L2VPN-
SIG] section 5.1.1.2. A small difference exists here in that the
"discovery" process occurs when an ATM SETUP message arrives.
It should be noted, that the pseudowire setup remains a pair of uni-
directional labels assigned by two essentially independent label
requests. It is only the triggering of the reverse label request
that is tied to the forward label request. Further [PWE3-CP] does
not carry bandwidth parameters at all.
6.3. Mapping Identifiers
In [PWE3-CP], an IP address identifies the egress node, and the (T)AI
identifies the egress port and DLCI or VPI/VCI. In ATM, an AESA
identifies both the egress node and port, and the DLCI or VPI/VCI is
carried as a literal in the SPVC IE.
Two issues must be addressed. First a mapping between ATM and IP
addresses is needed. Second a means of translating between the ATM
port and SPVC IE and the AI used in [PWE3-CP].
6.3.1. Mapping Addresses
OSI Network Service Access Point Addresses include an Authority and
Format Identifier (AFI). The AFI value 35 has been assigned to the
IANA. Within this format a two-octet Internet Code Point (ICP) field
is available for assignment by the IANA. Currently there is one code
point, 0, assigned for embedding IPv6 addresses. A format and code
point assignment has been proposed by the ATM Forum in [ATM-ipaddr].
That format is shown below.
Swallow & Spiegel Standards Track [Page 10]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
|--AFI (Authority &
| Format Identifier) Selector
| |--IDP (Initial Domain Part) |
V V |<---- HO-DSP ----->|<-- ESI -->|V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|3|0 0|I P v 4|0 0 0 0 0 0| |0|
|5|0 1|Address|0 0 0 0 0 0| |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HO-DSP High Order Domain Specific Part
ESI End System Identifier
Figure 3: NSAP with Embedded IPv4 Address
While it is common practice to carry the port number in the ESI
field, We note that there are six unused bytes in the HO-DSP as well
as the Selector Byte which could be used in a situation where the ESI
was not available.
The format to embed an IPv6 address in an NSAP address is defined in
[RFC1888]. In this format the only unused space is the Selector
Byte. This allows for the identification of 256 ports. If more
ports are needed, multiple addresses must be assigned.
|--AFI (Authority &
| Format Identifier) Selector
| |--IDP (Initial Domain Part) |
V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|3|0 0| I P v 6 A d d r e s s | |
|5|0 0| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NSAP with Embedded IPv6 Address
While it is expected that for IPv4 the ESI will commonly be used and
for IPv6 the Selector Byte must be used, the discussion below will
simply refers to a generic port field.
6.3.2. Mapping Port and SPVC IEs to AIs
It is proposed that the Port and SPVC IE values be mapped into the
AII. The SPVC IE has three formats, one each for Frame Relay, ATM
SPVC, and ATM SPVP. Each of these will be mapped into three [to be
assigned] AII types. [If there is an issue with IANA allocating
Swallow & Spiegel Standards Track [Page 11]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
three, one, with some form of sub-typing will do.]
6.4. Configuration
PAEs: For each Permanent Virtual Connection, the PAE is configured
with the target AESA and DLCI or VPI/VCI.
AEs: AEs are configured with the AESA prefix representing the set of
PSN nodes reachable through its link(s) to the PSN. Multiple
prefixes may be configured to allow choices of optimum nodes to
reach and to allow reachability to a larger set of nodes,
should some other AE or ME fail. The advertisement into the
ATM network's routing protocol (e.g.PNNI) should be withdrawn
if the associated link(s) have failed.
PMEs: PME require no special configuration. They are simply
configured with the (T)AII of each of their ACs.
MEs: MEs must be able to encode and parse the [to be assigned] AII
types. Associated with each of these AII type is an AII format
(used to form TAIIs) and rules for how to extract the port from
the ATM called party address. .fi
6.5. Procedures
6.5.1. Procedures within the ATM Network
In an SPVC, one end is designated as the 'owner' and is responsible
for initiating the connection. In order to simplify the interwork-
ing, this solution proposes that SPVCs always be initiated from the
ATM side. This obviates any need to communicate bandwidth informa-
tion across the PSN to the ATM network.
The AEs as the owner of the connection, initiates PNNI signaling as
it normally would. Finding a longest match associated with one or
more of the AEs it performs normal PNNI routing selection and sends a
SETUP message which includes the SPVC IE.
When the SETUP message arrives at the AE, it performs normal PNNI
signaling processing and forwards the message across the PNNI, AINI
or UNI to the ME.
Swallow & Spiegel Standards Track [Page 12]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
6.5.2. Procedures for the ME
When the ME receives a SETUP message, performs ATM admission control.
Additionally, the ME may perform additional checks to determine if it
has the necessary resources to support the pseudowire connection in
the forward direction. For example, in some network deployments it
may determine if a PSN tunnel can be established in order to satisfy
QoS or restoration requirements.
In the event that the call cannot be admitted, the ME SHOULD set an
appropriate cause code, assuming that it is capable of supporting
crankback procedures.
When the ME has successfully performed ATM admission control, it
splices the call to a pseudowire using the signaling procedures of
[L2VPN-SIG]. First, it extracts the destination IP address from the
ATM called party address. It then determines if a LDP session exists
with this node. If not, one is initiated. It then examines the SPVC
IE to determine the type of service which is being requested. Based
on the service type it selects AII type and format. It then extracts
the port, VPI, VCI, and/or DLCI information as appropriate to the
service and formats an AII. It formats an SAI using the same encod-
ing rules, using the port the setup message was received on and the
Connection Identifier. This AI becomes the handle which will be used
to locate the context for this call. It then sends a Label Mapping
message to the target node.
When it receives a Label mapping message from the target node, it
uses the TAI to locate the call context and completes the ATM call.
[Note: while the details of the ATM call processing and crankback
codes is a subject for other Fori and thus beyond the scope of the WG
(and IETF), an informative appendix will be added if the WG so
desires.]
6.5.3. Procedures for the PME
The procedures for the PME follow [L2VPN-SIG] with no changes. That
is, the PME uses the TAI to identify interface and DLCI or VPI/VCI.
No decoding of the TAII is necessary; the AI and AC are simply con-
figured as in [L2VPN-SIG].
If the forward label mapping completed successfully, the PME responds
with an LDP label mapping message in the reverse direction. The same
encapsulation as the forward direction MUST be signaled.
Swallow & Spiegel Standards Track [Page 13]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
6.5.4. Call Completion
When the ME receives the label mapping message, it uses the TAI to
(i.e. what it sent as the SAI) locate the context for this call and
then completes the ATM call by sending a CONNECT message back to the
PAE.
6.6. Handling Re-assembly
When an ME detects that the requested service is Frame Relay, by
default it will perform AAL5 re-assembly for Frame Relay SPVCs. In
this case the AAL5 SDU frame mode encapsulation as defined in
[PWE3-ENCAPS] is RECOMMENDED.
On a per ATM/PSN interface basis, an ME may be configured to not per-
form re-assembly for Frame Relay. No per circuit selection is pro-
vided. In this case the RECOMMENDED encapsulation is ATM N-to-1 Cell
Mode.
Both ATM SPVCCs and SPVPCs are encapsulated using one of the cell-
mode encapsulations. The RECOMMENDED encapsulation is ATM N-to-1
Cell Mode.
[As noted in the "Issues" section below, the Frame Relay format of
the SPVC IE may not be available on some ATM equipment. Alternative
means of determining that the service is Frame Relay can be achieved
in many cases by examining some combination of the .
7. Issues
The Frame Relay format for the SPVC IE was added later. Some ATM
equipment still uses the ATM SPVC format with the DLCI encoded in the
VPI/VCI fields. To support these switches without change, and still
allow AAL5 reassembly to be done at the ME, some other means of indi-
cating that the circuit is Frame Relay needs to be established.
Swallow & Spiegel Standards Track [Page 14]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
8. Security Considerations
This document represents a straightforward application of [L2VPN-
SIG]. It poses no new security considerations over and above those
identified in that document.
9. Acknowledgments
The authors would like to thank Chris Metz and Chandra Krishnamurthy
for their input to this document.
10. References
10.1. Normative References
[LDP] Andersson, L. et al., "LDP Specification", RFC 3036,
January 2001.
[L2VPN-SIG] Rosen, E.& Radoaca, V, "Provisioning Models and Endpoint
Identifiers in L2VPN Signaling",
draft-ietf-l2vpn-signaling-00.txt, September 2003.
[PWE3-CP] Martini, L. & Rosen, E., "Pseudowire Setup and Maintenance
using LDP", draft-ietf-pwe3-control-protocol-04.txt,
October 2003.
[PWE3-ENCAP] Martini, et al., "Encapsulation Methods for Transport of
ATM Cells/Frame Over IP and MPLS Networks",
draft-ietf-pwe3-atm-encap-03.txt, October 2003.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[PWE3-IANA] Townsley, M., "IANA Allocations for pseudo Wire Edge to
Edge Emulation (PWE3)",
draft-ietf-pwe3-iana-allocation-04.txt, April 2004.
[ATM-AINI] ATM Forum, "ATM Inter-Network Interface Specification
Version 1.1 (AINI 1.1)", af-cs-0125.002, September 2002
[ATM-UNI] ATM Forum, "ATM User-Network Interface (UNI) Signalling
Swallow & Spiegel Standards Track [Page 15]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
Specification Version 4.1", af-sig-0061.002, April 2002
[PNNI] ATM Forum, "Private Network-Network Interface Specification
Version 1.1", af-pnni-0055.001, April 2002
[ATM-ipaddr] ATM Forum, "IP-Based Addressing Version 1.0",
str-cs-ipaddr-01.01, October 2003
[RFC1888] Bound, J., et al., "OSI NSAPs and IPv6", RFC 1888,
August 1996.
11. Authors' Addresses
George Swallow
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719
Email: swallow@cisco.com
Ethan Mickey Spiegel
Cisco Systems, Inc.
3700 Cisco Way
San Jose, CA 95134
Email: mspiegel@cisco.com
12. Full Copyright and Intellectual Property Statements
Copyright (C) The Internet Society (2004). 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 INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Swallow & Spiegel Standards Track [Page 16]
Internet Draft draft-swallow-pwe3-spvc-iw-02.txt February 2005
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 assur-
ances 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.
Swallow & Spiegel Standards Track [Page 17]