One document matched: draft-swallow-pwe3-spvc-iw-01.txt
Differences from draft-swallow-pwe3-spvc-iw-00.txt
Network Working Group George Swallow
Internet Draft Cisco Systems, Inc.
Category: Standards Track
Expiration Date: January 2005
Mickey Spiegel
Cisco Systems, Inc.
July 2004
Soft Permanent Virtual Circuit Interworking between PWE3 and ATM
draft-swallow-pwe3-spvc-iw-01.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 (2004).
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-01.txt July 2004
[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 ............................................. 13
6.5.1 Procedures within the ATM Network ...................... 13
6.5.2 Procedures for the ME .................................. 13
6.5.3 Procedures for the PME ................................. 14
6.5.4 Call Completion ........................................ 14
6.6 Handling Re-assembly ................................... 14
7 Issues ................................................. 15
8 Security Considerations ................................ 15
9 Acknowledgments ........................................ 15
10 References ............................................. 15
10.1 Normative References ................................... 15
10.2 Informative References ................................. 16
11 Authors' Addresses ..................................... 16
12 Full Copyright and Intellectual Property Statements .... 17
Swallow & Spiegel Standards Track [Page 2]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
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
maintained 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-01.txt July 2004
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
limited to the edge nodes supporting a particular connection and
allowing 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-01.txt July 2004
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
connection 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
network to automatically reroute / re-establish the circuit when
failures 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-01.txt July 2004
3.1. Configuration
All per circuit configuration must be limited to the edge nodes. In
particular the solution must not necessitate any per circuit
configuration on the nodes which 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-01.txt July 2004
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
network, 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
[PWE3-CP]. 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
further designated by their role in the call, with the operative
terms being source and target of the call. Thus we also have the
terminology, source attachment identifier (SAI), source attachment
individual identifier (SAII), target attachment identifier (TAI), and
target attachment individual identifier (TAII). The source and target
designations are only relevant from the perspective of the pseudowire
control 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.
Swallow & Spiegel Standards Track [Page 7]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
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.
Thus common practice is to use the ESI to carry the port information.
Swallow & Spiegel Standards Track [Page 8]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
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
document 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
circuit are carried in the setup message.
A paradigm analogous to the active/passive roles in SPVC setup above
for pseudowires is known as single sided provisioning. These
procedures are defined in draft-rosen-ppvpn-l2-signaling-03.txt
[L2VPN-SIG] section 5.1.1.2. A small difference exists here in that
Swallow & Spiegel Standards Track [Page 9]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
the "discovery" process occurs when an ATM SETUP message arrives.
It should be noted, that the pseudowire setup remains a pair of
unidirectional 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.
|--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
Swallow & Spiegel Standards Track [Page 10]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
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. It is therefore proposed that three special AGIs
be configured to serve as format identifiers for the necessary AII
formats. As the values of these AGIs are completely under the
control of the network operator, no specific values are specified.
All that is required is that values be assigned which allow the
parsing of the AII. We also note that if the AII is formatted as in
the second suggestion below, only one AGI is absolutely necessary,
since that AII is self identifying.
The exact mapping between the port and SPVC IE is also beyond the
scope of this document. All that is required is that the mapping
preserve all the information contained in the port field and the SPVC
IE. Since the resultant string will be compared with the AI
information configured at the target node, it is highly recommended
that the mapping be done in a human readable format.
An example format for a mapping of an SPVC IE specifying an ATM VC,
might be to translate the ESI, VPI, and VCI values to ASCII decimal
Swallow & Spiegel Standards Track [Page 11]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
strings with any leading zeroes suppressed. And then format the TAII
as a concatenation of the three strings with some delimiters. So for
port 30, vpi 11, vc 232 one might format the TAII as 30/11/232 or as
PORT30VPI11VCI232.
We also note in passing that while we have referred to literal port,
DLCI, VPI, and VCI values, we note that there is nothing in this
solution that demands this be so. The discussion has been couched in
these terms only because this is the common practice. Since an AI
can be mapped to any arbitrary attachment circuit, the values could
be symbolic. Operators may find this convenient, particularly for
the port. Such indirection would allow the attachment port to be
re-homed within a PWE edge box without reconfiguration on the ATM
side.
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 are configured with the AGIs of each service they support
and the (T)AII of each configured AC.
MEs: MEs are configured with special AGI values for each service (FR
PVCC, ATM PVCC, ATM PVPC) it supports. Associated with each of
these AGI values is an AII format (used to form TAIIs) and
rules for how to extract the port from the ATM called party
address. Also associated with each AGI is a pool of (S)AIIs
which can be assigned "on the fly" as SAIs to incoming ATM
calls.
Swallow & Spiegel Standards Track [Page 12]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
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
interworking, this solution proposes that SPVCs always be initiated
from the ATM side. {This alleviates any need to communicate
bandwidth information across the PSN to the ATM network. better
wording needed}
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 AINI or UNI
to the ME.
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 the configured AGI value and AII
format. It then extracts the port, VPI, VCI, and/or DLCI information
as appropriate to the service and formats a TAI. It then dynamically
an AII from the pool associated with this AGI and forms a SAI. 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
Swallow & Spiegel Standards Track [Page 13]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
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
configured as in [L2VPN-SIG].
If the 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.
6.5.4. Call Completion
When the ME receives the label mapping message, it uses the TAI to
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
perform re-assembly for Frame Relay. No per circuit selection is
provided. 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 .
Swallow & Spiegel Standards Track [Page 14]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
7. Issues
1. Should support for Frame Relay signaling be added to this draft?
2. 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 indicating that the circuit is Frame Relay needs to be
established.
3. The configuration of a per service pool of AIIs at the ME can be
eliminated by formating a SAII on the fly based on the ME's
incoming interface and the VPI/VCI in use on that interface.
Details will be supplied in the next revision of this draft.
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.
Swallow & Spiegel Standards Track [Page 15]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
[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
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
Swallow & Spiegel Standards Track [Page 16]
Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004
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
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.
Swallow & Spiegel Standards Track [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 00:35:40 |