Network Working Group M. Bocci, Ed.
Internet-Draft Alcatel
Expires: May 16, 2005 M. Jensen
Equipe Communications
D. Proch
Marconi Communications
J. Sugimoto
Nortel Networks
H. Shah
Ciena Corp.
November 15, 2004
Signalling Interworking for Asynchronous Transfer Mode Virtual
Private Wire Service
draft-bocci-l2vpn-pnni-mpls-iw-02
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. This document may not be modified, and derivative works of
it may not be created, except to publish it as an RFC and to
translate it into languages other than English.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 16, 2005.
Copyright Notice
Bocci, et al. Expires May 16, 2005 [Page 1]
Copyright (C) The Internet Society (2004).
Internet-Draft PNNI-L2VPN Interworking November 2004
Abstract
This Internet Draft describes a method for control plane interworking
for Asynchronous Transfer Mode (ATM) pseudo wires, where Provider
Edge nodes (PEs) on both sides of an MPLS Packet Switched Network
(PSN) connect edge ATM networks using the Private Network-Network
Interface (PNNI) or the ATM Inter-Network Interface (AINI). In this
method, ATM signalling and routing messages are tunnelled over the
PSN using dedicated pseudo wires, enabling ATM pseudo wires carrying
user traffic to be established and release dynamically by ATM. The
method does not require changes to existing IETF defined protocols in
order to support all features of PNNI and AINI.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions Used in this Document . . . . . . . . . . . . 3
1.2 Additional Contributors and Acknowledgements . . . . . . . 3
1.3 Objectives and Scope . . . . . . . . . . . . . . . . . . . 3
1.4 Relevance . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 A Note on Terminology Differences . . . . . . . . . . . . 5
2. ATM Signalled to ATM Signalled Networks . . . . . . . . . . . 6
2.1 Tunnelling of the ATM Control Plane . . . . . . . . . . . 6
2.1.1 Extending ATM Signalling Across the PSN . . . . . . . 7
2.1.2 Extending PNNI Routing Across the PSN . . . . . . . . 8
2.1.3 ATM Control Plane Association to PSN Tunnels . . . . . 8
2.1.4 Encapsulation Format . . . . . . . . . . . . . . . . . 9
2.1.5 Quality of Service . . . . . . . . . . . . . . . . . . 9
2.2 Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 PSN-based Protection of the PSN Tunnel . . . . . . . . 10
2.2.2 PNNI-based Protection of the Pseudo Wires . . . . . . 10
2.3 Operations, Administration and Maintenance . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 Normative References . . . . . . . . . . . . . . . . . . . . 14
5.2 Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Bocci, et al. Expires May 16, 2005 [Page 2]
Internet-Draft PNNI-L2VPN Interworking November 2004
1. Introduction
1.1 Conventions Used in this Document
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].
1.2 Additional Contributors and Acknowledgements
Additional contributors to this document are:
Mustapha Aissaoui, Alcatel, mustapha.aissaoui@alcatel.com
David Watkinson, Alcatel, david.watkinson@alcatel.com
George Matey, Equipe Communications, george@equipecom.com
John Rutemiller, Marconi Communications, john.rutemiller@marconi.com
Ghassem Koleyni, Nortel Networks, ghassem@nortelnetworks.co
m
The authors also gratefully acknowledge the input of Peter Roberts,
Dimitri Papadimitriou and Jack Pugaczewski.
1.3 Objectives and Scope
This informative document extends [7] by including mechanisms for
interworking with attachment circuits that are Asynchronous Transfer
Mode (ATM) Soft Permanent Virtual Channels or Soft Permanent Virtual
Paths (SPVCs/SPVPs) and ATM Switched Virtual Channels or Switched
Virtual Paths (SVCs/SPVCs) for Multi Protocol Labels Switching (MPLS)
based Packet Switched Networks (PSNs).
Service providers are introducing new PSN based networks and are
looking for a seamless way to extend the reach of existing ATM
services to new sites attached to this PSN network. One important
capability which is used in the existing ATM networks is ATM switched
services. These are mainly SPVC services, and to a lesser extent SVC
services. SPVC services are critical in today's networks as they
allow simplified provisioning of the ATM services by configuring the
endpoints only. They also allow dynamic traffic engineering and a
faster restoration in the case of a network failure. Finally, ATM
SPVCs extend connectivity to non-ATM endpoints, such as Frame Relay
and Ethernet, on an ATM switch. Thus ATM SPVCs support both native
ATM, and non-ATM services and are used in both network and service
interworking deployment scenarios. Non-ATM services continue to
drive deployments of ATM SPVCs. By transparently supporting ATM
switched services over the PSN, existing provisioning tools and
operational procedures may be used. It is therefore important to
provide methods for interworking ATM switched services and PSN based
services such as Virtual Private Wire Service (VPWS).
Bocci, et al. Expires May 16, 2005 [Page 3]
Internet-Draft PNNI-L2VPN Interworking November 2004
In this document, the attachment circuits on both the ingress and
egress Provider Ede Nodes (PEs) are either ATM SPVCs/SPVPs or ATM
SVCs/SVPs. In addition, ATM Private Network-Network Interface (PNNI)
routing may run between the ingress and egress PEs.
There are no methods to signal port connections in ATM, and thus
there is no intent to provide VPWS services for transporting an
entire ATM port across the PSN using these services. These services
should use standard VPWS services instead. This may include the
tunnelling of many VC's including PNNI Routing Control Channels
(RCCs) and signalling channels within the same port pseudo wire.
There are no control plane interactions between ATM
signalling/routing and the underlying PSN, and therefore there are no
protocol considerations.
This document describes methods and procedures specified in ATM Forum
Specification "ATM-MPLS Network Interworking Signalling
Specification, Version 1.0"[5].
1.4 Relevance
This informative document shows how the existing Layer 2 Virtual
Private Network framework (L2VPN)[7] and the Pseudo Wire Emulation
Edge-to-Edge (PWE3) architecture [3] can be leveraged to tunnel ATM
signalling and routing through the PSN. We show how ATM pseudo wires
can be established and released as required by the ATM switched
service, without requiring changes to existing IETF protocols e.g.
[2], [6], [8]. This addresses work item 2 of the Layer 2 VPN working
group charter for signalling layer 2 information.
1.5 Terminology
This document uses the following terms. Formal definitions of some
of these terms can be found in [3]
ATM Inter Network An ATM Forum specification for signaling to
Interface (AINI) establish point-to-point and point-to-
multipoint connections across an ATM
network
Attachment Circuit The physical or virtual circuit attaching
(AC) a PE to a CE. In the context of the
application described here, this will be an
ATM VCI or VPI.
Integrated An ATM Forum specification allowing any ATM
Link Management device to be provided with status and
Interface (ILMI) configuration information.
Bocci, et al. Expires May 16, 2005 [Page 4]
Internet-Draft PNNI-L2VPN Interworking November 2004
Private Network ATM Forum specification to establish point
to Network Interface to point and point to multipoint connections
across an ATM network including source,
routing, crankback, and alternate routing
Provider Edge (PE) A device that provides PWE3 to a CE.
Pseudo Wire (PW) A mechanism that carries the essential
elements of an emulated service from one PE
to one or more other PEs over a PSN.
Pseudo Wire Emulation A mechanism that emulates the essential
Edge to Edge (PWE3) attributes of a service (such as an ATM
VCC) over a PSN.
PSN Tunnel A tunnel across a PSN inside which one or
more PWs can be carried.
Routing Control An ATM connection that carries PNNI routing
Channel (RCC) messages between PNNI neighbouring peer
nodes
Tunnel A method of transparently carrying
information over a network.
Virtual Private A point-to-point circuit (link) connecting
Wire Service (VPWS) two Customer Edge devices.
1.6 A Note on Terminology Differences
There are some differences in terminology between the IETF, and that
used by the ATM Forum in [5]. Figure 2 summarizes the main terms.
IETF Term | ATM Forum Term
-------------------|--------------------
Pseudo Wire | Interworking LSP
Pseudo Wire Label | Interworking Label
PSN Tunnel | Transport LSP
Provider Edge | Interworking Network Element
Figure 2: Terminology
Bocci, et al. Expires May 16, 2005 [Page 5]
Internet-Draft PNNI-L2VPN Interworking November 2004
2. ATM Signalled to ATM Signalled Networks
ACs PSN ACs
ATM ATM
+------+ Tunnel +------+
+-----+ | PE1 |==============| PE2 | +-----+
| CE1 |-----------.........PW..........-------------| CE2 |
+-----+ | VPWS | | VPWS | +-----+
| |==============| |
+------+ +------+
Figure 3: Architecture
Figure 3 shows the general architecture for ATM VPWS. The attachment
circuits are ATM VCCs or VPCs that span an ATM network. ATM
connections are mapped to Pseudo Wires (PWs) in the PSN tunnel. ATM
SVC services start and terminate on the attached CE devices, while
the signalling for the SPVC services originates and terminates on the
ATM switches in the ATM networks that the CEs are physically attached
to, or on the PE where there is only a single hop path netween the CE
and the PE. The objective is to provide service over a PSN without
impacting the ATM signalling that occurs between the CE devices, and
without requiring changes to non-ATM protocols between PE1 and PE2
e.g. MPLS [2], the PWE3 control protocol [8], or RSVP-TE [6].
ATM signalling and routing typically operates over PNNI [10] or AINI
[11] interfaces. Signalling and routing messages for these protocols
are carried on dedicated ATM VCCs. These are known as Signalling
Channels for signalling messages and Routing Control Channels (RCC
s)
for PNNI routing messages. For ATM link managent messages, an ILMI
channel [13] may be used. For AINI, static ATM routing is assumed
and so no RCC is present.
2.1 Tunnelling of the ATM Control Plane
The terminology used in this section follows the L2VPN naming
conventions. The use of the pseudo wire label in this section can be
related to the use of the interworking label within [5].
Bocci, et al. Expires May 16, 2005 [Page 6]
Internet-Draft PNNI-L2VPN Interworking November 2004
ACs PSN ACs
ATM ATM
+-----+ Tunnel +------+
_____ | PE1 |=============| PE2 | _____
( )--Sig---- ......PW.(SIG)..... ------Sig---( )
( ATM ) |VPWS | | VPWS | ( ATM )
(network) | | | | (network)
( )--RCC---- ......PW.(RCC)..... ------RCC---( )
~~~~~~~ | |=============| | ~~~~~~~
+-----+ +------+
Figure 4: Extending ATM Signalling and Routing Across the PSN
Figure 4 shows how ATM signalling and routing is extended across the
PSN between attached ATM networks. In the case of ILMI, a PW would
also be present that represents an ILMI channel in the ATM network.
2.1.1 Extending ATM Signalling Across the PSN
In the case of signalling, a bidirectional PW MUST established, using
the PW signalling protocol [8], or by configuration. to carry the
ATM signalling channel messages transparently across the PSN for
either PNNI or AINI. This allows all of the existing and future ATM
signalling capabilities to be carried transparently.
[5] explains how ATM signalling is extended across the PSN to
advertise PW labels between PE1 and PE2. The PNNI and AINI protocol
extensions described in [5] add an Interworking Information Element
(IE) which supports label exchange between the PE pair for the ATM
connection pseudo wire and the negotiation of encapsulation methods
for the connection. There is no requirement for any ATM capable
system, other than the PEs, to understand or support the Interworking
IE. Therefore legacy systems can take advantage of the interworking
capabilities without need for software modifications. Since ATM
signalling messages are carried transparently between the PE pairs,
there are no protocol considerations for the PSN related to the
signalling and establishment of ATM connection pseudo wires.
The pseudo wire label for an ATM connection is carried between the
two PEs in the Interworking IE within the PNNI or AINI signalling
messages. As the label is significant only to the PE devices at
either end of the PSN tunnel, this IE can be added to the signalling
message by the PE. Where other non-ATM VPWS services are also
supported by the PE and pseudo wire labels are allocated from the
same label space as ATM pseudo wires, the PE will need to manage
common resources between multiple control plane protocols e.g. [5]
Bocci, et al. Expires May 16, 2005 [Page 7]
Internet-Draft PNNI-L2VPN Interworking November 2004
and [8]. This is a common capability in current PE devices.
Implementations should provide a mechanism to restrict the maximum
the number of PWs that can be established on the PSN tunnel so that
the PW label space in the downstream PE does not become exhausted.
The details of this mechanism are outside the scope of this document.
2.1.2 Extending PNNI Routing Across the PSN
ATM Routing is also extended between PE1 and PE2 as explained in [5].
Before the ATM routing can start exchanging ATM reachability across
the PSN tunnel, a PNNI RCC MUST be set up between PE1 and PE2 in
Figure 4. As in the case of signalling, the PW control protocol [8],
or configuration, sets up a bidirectional PW to carry the ATM routing
messages in each direction. This PW represents an RCC between PE1
and PE2.
For PNNI, the PSN tunnel can be modelled as a PNNI link between PE1
and PE2, thus extending ATM reachability across the MPLS network
using any desired meshing. Therefore, PNNI Routing can take
advantage of any parallel or alternate tunnels through the MPLS
network. This includes the use of multiple hops (i.e. a sparse
mesh), whereby the pseudo wire leaves one PSN tunnel at a given PE,
is processed by the ATM signalling on that PE, and enters another PSN
tunnel before terminating at the egress PE.
PNNI Routing can also properly traffic engineer the usage of any
traffic engineered MPLS PSN tunnels. This is achieved by PNNI
Routing advertising the available bandwidth of an MPLS PSN tunnel for
use by the pseudo wires to the attached ATM networks. Any of the ATM
addressing formats can be used in these network situations and is
fully transparent to the PSN.
This method supports all currently deployed PNNI network scenarios,
including PNNI Hierarchy.
Note that signalling of the PSN tunnel is beyond the scope of this
document.
2.1.3 ATM Control Plane Association to PSN Tunnels
There is no stipulation or restriction on how PSN Tunnels are
established between two PE devices. The architecture requires at
least one bidirectional PSN Tunnel between two PE devices, but can
also support multiple PSN Tunnels modeled as a single PNNI or AINI
link. In its simplest default case, a single PSN Tunnel is
represented as a single PNNI or AINI link. The control pseudo wires
i.e those representing Signalling Channels and RCCs, are carried
Bocci, et al. Expires May 16, 2005 [Page 8]
Internet-Draft PNNI-L2VPN Interworking November 2004
"in-band" - that is within the PSN tunnel whose ATM PWs they control.
In other cases, where multiple PSN Tunnels may be used to support QoS
guarantees, resiliency requirements or more efficient usage of PSN
resources, a single set of control pseudo wires may be used to manage
the resources of all PSN tunnels available for ATM established
between the two PEs. These control pseudo wires may be carried
within one of the PSN Tunnel pairs, but are not required to be
associated directly with the tunnels they control.
2.1.4 Encapsulation Format
Any of the ATM PW encapsulations can be used for both PWs carrying
user data, and those used for RCC, ILMI or Signalling channels. The
PW types as defined in [4] are used for user connections based on the
signalled ATM parameters, as defined in [5]. The choice of
encapsulation will depend on its ability to support the requirements
of the ATM service, as described in [4].
Negotiation of an encapsulation mode is a local matter between a pair
of PEs. While an ATM end system may add the Interworking IE to
request a specific encapsulation mode at any interworking interface,
it is not required. The PE should support a default mode for
connections signalled without a specific encapsulation indicated.
Alternatively, the PE may select from among its supported
encapsulations based on local policies. It is expected that the
default will be to use a cell mode pseudo wire.
2.1.5 Quality of Service
Many of the ATM QoS guarantees can continue to be met through the PSN
core. This is possible with the use of traffic-engineered MPLS
DiffServ PSN tunnels [14]. This is discussed in more detail in [9]
section 9 and Appendix V. PNNI can use these mappings to advertise
the resources available for ATM connections on the PSN tunnel to the
attached ATM networks. The attached ATM networks will see these
resources as native ATM resources. Generalized Connection Admission
Control (GCAC) of PNNI running in the attached ATM networks can then
use these advertised resources as a part of the route selection
decision.
Note that the translation of ATM traffic parameters into bandwidth
parameters for utilization in the PSN needs to take into account the
overhead associated with the PW type.
2.2 Resiliency
The tunnelling of PNNI through the PSN means that either PSN-based
Bocci, et al. Expires May 16, 2005 [Page 9]
Internet-Draft PNNI-L2VPN Interworking November 2004
protection mechanisms may be used to provide resiliency, or
optionally PNNI-based mechanisms, or both. Failure detection timers
of each mechanism may need to be adjusted in order to allow one
mechanism priority over the other.
2.2.1 PSN-based Protection of the PSN Tunnel
The PSN tunnel can be protected from failures in the PSN using PSN
specific mechanisms, for example MPLS Fast Reroute [12]. Whichever
mechanism is chosen, the PSN tunnel needs to continue to support any
QoS guarantees given to the ATM connections following any restorative
action.
2.2.2 PNNI-based Protection of the Pseudo Wires
PNNI has its own mechanisms to provide resiliency in a native ATM
network. These same mechanisms can be used without modification to
provide protection for the ATM pseudo wires carried through the PSN.
Two examples are given below.
ACs PSN ACs
ATM ATM
PNNI +------+ PSN Tunnel +------+ PNNI
+-----+ | PE1 |==============| PE2 | +-----+
| CE1 |-RCC------ ........PW.......... ----------| CE2 |
| |-SIG------ .................... ----------| |
| |\ | | | | /| |
| |\\ | VPWS | | VPWS | //| |
+-----+ \RCC | |==============| | // +-----+
\\ +------+ | | //
SIG\\ +------+ PSN Tunnel | | //
\\ | PE3 |==============| | //
\\--- .................... ---//
\--- .................... ---/
| |==============| |
+------+ +------+
Figure 5: Dual Homing Example
Figure 5 shows an example of multi-homing of the ATM network into the
PSN cloud, using PNNI rerouting to protect against failures of PE1 or
the PSN tunnel. An additional PE, PE3. is shown in the network
above that is connected to the ATM network, together with an
additional PSN tunnel from PE3 to PE2. Both PSN tunnels are
configured as PNNI links, with associated RCCs and Signalling
Channels. If PSN tunnel PE1->PE2 fails, then PNNI can automatically
Bocci, et al. Expires May 16, 2005 [Page 10]
Internet-Draft PNNI-L2VPN Interworking November 2004
reroute all ATM connections on PSN tunnel PE1->PE2 to PSN tunnel
PE3->PE2.
ACs PSN ACs
ATM ATM
PNNI +------+ Tunnel +------+ PNNI
+-----+ | PE1 |==============| PE2 | +-----+
| CE1 |-----------.........PW..........-------------| CE2 |
+-----+ | VPWS |==============| VPWS | +-----+
| | | |
| |======| |=====| |
| |===== | | ====| |
+------+ || || +------+
|| ||
+-------+
| |
| PE3 |
| |
+-------+
Figure 6: Multi-Hop ATM Routing
Figure 6 shows a third PE, PE3, attached to an additional ATM
network. PE3 is connected to PE1 and PE2 using PSN tunnels. All
three tunnels (PE1->PE2, PE1->PE3, PE3->PE2) can be configured as
PNNI links so that PNNI can automatically use the alternate path
formed by PSN tunnels PE1->PE3 and then PE3->PE2 if tunnel PE1->PE2
fails. PE3 simply acts as a transit ATM/PNNI node in this scenario.
2.3 Operations, Administration and Maintenance
ATM OAM is tunnelled through the PSN, as described in [4]. ATM OAM
is notified of PSN tunnel failures in the same way as it handles port
or virtual port failures in an ATM switched network. The mechanisms
for detecting tunnel failures depends on the PSN mechanisms used and
is outside the scope of this document. Fault management procedures
for ATM PWs are outside the scope of this document.
Bocci, et al. Expires May 16, 2005 [Page 11]
Internet-Draft PNNI-L2VPN Interworking November 2004
3. Security Considerations
Extended PNNI uses pseudo wires to transport ATM signalling and
routing across a PSN. 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 then a native ATM service.
Bocci, et al. Expires May 16, 2005 [Page 12]
Internet-Draft PNNI-L2VPN Interworking November 2004
4. IANA Considerations
This document has no IANA actions.
Bocci, et al. Expires May 16, 2005 [Page 13]
Internet-Draft PNNI-L2VPN Interworking November 2004
5. References
5.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Rosen, E., "Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[3] Bryant, S., "The PWE3 Architecture,
draft-ietf-pwe3-arch-07.txt", March 2004.
[4] Martini, L., "Encapsulation Methods for Transport of ATM
Cells/Frame Over IP and MPLS Networks,
draft-ietf-pwe3-atm-encap-07.txt", October 2004.
[5] ATM Forum Technical Committee, "ATM-MPLS Network Interworking
Signalling Specification, Version 1.0, AF-CS-0197.000", August
2003.
5.2 Informative References
[6] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[7] Andersson, L., "L2VPN Framework,
draft-ietf-l2vpn-l2-framework-05.txt", June 2004.
[8] Martini, L., "Pseudowire Setup and Maintenance using LDP,
draft-ietf-pwe3-control-protocol-11.txt", October 2004.
[9] ATM Forum Technical Committee, "ATM-MPLS Network Interworking,
Version 2.0, AF-AIC-0178.001", August 2003.
[10] ATM Forum Technical Committee, "Private Network-Network
Interface Specification, Version 1.1 (PNNI 1.1),
af-pnni-0055.002", April 2003.
[11] ATM Forum Technical Committee, "ATM Inter-Network Interface
Specification, Version 1.1 (ANNI 1.1), af-cs-0125.002",
September 2002.
[12] Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels,
draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt", September 2004.
[13] ATM Forum Technical Committee, "ILMI (Integrated Link
Management Interface)", September 1996.
Bocci, et al. Expires May 16, 2005 [Page 14]
Internet-Draft PNNI-L2VPN Interworking November 2004
[14] Le Faucheur, F., "Multi-Protocol Label Switching (MPLS) Support
of Differentiated Services", RFC 3270, May 2002.
Authors' Addresses
Matthew Bocci (editor)
Alcatel
Phone: +44 20 8883 2782
EMail: matthew.bocci@alcatel.c
o.uk
Martin Jensen
Equipe Communications
Phone: +1 978 795 2140
EMail: martin@equipecom.com
Daniel Proch
Marconi Communications
Phone: +1 724 742 7746
EMail: daniel.proch@marconi.com
Jeff Sugimoto
Nortel Networks
Phone: +1 613 763 1392
EMail: sugimoto@nortelnetworks.com
Himanshu Shah
Ciena Corp.
Phone: +1 508 489 2196
EMail: hshah@ciena.com
Bocci, et al. Expires May 16, 2005 [Page 15]
Internet-Draft PNNI-L2VPN Interworking November 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bocci, et al. Expires May 16, 2005 [Page 16]
