Internet DRAFT - draft-martini-pwe3-MH-PW-requirements
draft-martini-pwe3-MH-PW-requirements
Network Working Group Luca Martini (Editor)
Internet Draft Cisco Systems Inc.
Expiration Date: June 2005
Matthew Bocci (Editor) Nabil Bitar (Editor)
Alcatel Verizon
December 2004
Requirements for inter domain Pseudo-Wires
draft-martini-pwe3-MH-PW-requirements-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.
Abstract
This document describes the necessary requirements to allow a service
provider to extend the reach of pseudo-wires across multiple domains.
These domains can be autonomous systems under one provider
administrative control, IGP areas in one autonomous system, different
autonomous systems under the administrative control of two or more
Martini, et al. [Page 1]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
service providers, or administratively established pseudowire
domains.
Table of Contents
1 Specification of Requirements .......................... 2
2 Acknowledgements ....................................... 3
3 Introduction ........................................... 3
3.1 Scope .................................................. 3
3.2 Architecture ........................................... 3
4 Terminology ............................................ 6
5 Use Cases .............................................. 6
6 Multi-Hop Pseudo Wire Requirements ..................... 9
6.1 Architecture ........................................... 9
6.2 Traffic Engineering .................................... 10
6.3 Quality of Service ..................................... 10
6.4 Routing ................................................ 12
6.5 Signalling ............................................. 12
6.6 Operations and Maintenance (OAM) ....................... 12
7 Security Considerations ................................ 14
8 Full Copyright Statement ............................... 14
9 Intellectual Property Statement ........................ 14
10 Normative References ................................... 15
11 Informative References ................................. 15
12 Informative References ................................. 15
13 Author Information ..................................... 15
1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119
Martini, et al. [Page 2]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
2. Acknowledgements
The editors gratefully acknowledge the following contributors:
Dimitri Papadimitriou (Alcatel), Peter Busschbach (Lucent), Sasha
Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delorde
(France Telecom), Deborah Brungard (AT&T), Rahul Aggawal (Juniper),
Du Ke (ZTE), Cagatay Buyukkoc (ZTE).
3. Introduction
3.1. Scope
This document specifies requirements for extending pseudo-wires
across more than one packet switched network (PSN) domain. These
pseudo-wires are called multi-hop pseudo-wires (MH-PW). Requirements
for single-hop pseudo-wires (SH-PW) that extend edge to edge across
only one PSN domain are specified in [PWE3-REQ].
This document specifies additional requirements that apply to MH-PWs.
These requirements do not apply to PSNs that only support SH-PWs.
3.2. Architecture
The following two figures describe the reference models which are
derived from [PWE3-ARCH] to support PW emulated services.
Martini, et al. [Page 3]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Attachment Circuit (AC) Attachment Circuit (AC)
native ethernet service native ethernet service
Figure 1: PWE3 Reference Configuration
Figure 1 shows the PWE3 reference architecture [PWE3-ARCH]. This
architecture applies to the case where a PSN tunnel extends between
two edges of a single PSN domain to transport a PW with endpoints at
these edges.
Martini, et al. [Page 4]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
Native |<-----------Pseudo Wire----------->| Native
Layer2 | | Layer2
Service | |<-PSN1-->| |<--PSN2->| | Service
(AC) V V V V V V (AC)
| +----+ +-----+ +----+ |
+----+ | | PE1|=========| PE2 |=========| PE3| | +----+
| |----------|........PW1.........|...PW3........|----------| |
| CE1| | | | | | | | | |CE2 |
| |----------|........PW2.........|...PW4........|----------| |
+----+ | | |=========| |=========| | | +----+
^ +----+ +-----+ +----+ | ^
| Provider Edge 1 ^ Provider Edge 3 |
| | |
| | |
| PW switching point |
| (Optional PW adaptation function) |
| |
|<------------------- Emulated Service ------------------>|
Figure 2: PW switching Reference Model
Figure 2 extends this architecture to show a multihop case. PE1 and
PE3 provide PWE3 to CE1 and CE2. These PEs reside in different PSNs.
A PSN tunnel extends from PE1 to PE2 across PSN1, and a second PSN
tunnel extends from PE2 to PE3 across PSN2. PWs are used to connect
the Attachment circuits (ACs) attached to PE1 to the corresponding
ACs attached to PE3. Each PW on the tunnel across PSN1 is stitched to
a PW in the tunnel across PSN2 at PE2 to complete the multi-hop PW
(MH-PW) between PE1 and PE3. PE2 is therefore the PW switching point
and will be referred to as the PW switching provider edge (S-PE). PW1
and PW3 are segments of the same MH-PW while PW2 and PW4 are segments
of another pseudowire. PW segments of the same MH-PW (e.g., PW1 and
PW3) MUST be of the same PW type, but PSN tunnels (e.g., PSN1 and
PSN2) can be the same or different technology.
Note that although Figure 2 only shows a single S-PE, a PW may
transit more than one S-PE along its path.
Martini, et al. [Page 5]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
4. Terminology
[PWE3-REQ] provides terminology for PWE3. This document defines the
following additional terms:
- Ultimate PE (U-PE). A PE where the customer-facing ACs
(attachment circuits) are bound to a PW forwarder. An ultimate PE
is present in the first and last segments of a MH-PW.
- Single-Hop PW (SH-PW). A PW setup directly between two U-PE
devices.
- Multi-hop PW (MH-PW). A static or dynamically configured set of
two or more contiguous PW segments (SH-PW) that behave and
function as a single point-to-point PW. Each end of a MH-PW by
definition MUST terminate on a U-PE.
- PW Switching Point (S-PE). A PE capable of switching the control
and data planes of the preceding and succeeding PW segments (SH-
PW) in a MH-PW. A PW Switching Point is never the S-PE and the
U-PE for a MH-PW. A PW switching point runs necessary protocols
to setup and manage PW segments with other PW switching points
and ultimate PEs.
- PW Segment. A part of Multi-hop PW, which is set up between two
PE devices, U-PEs and/or S-PEs.
- PW access point address. A PWE3 payload (special service) is a
client, while the PSN is a server layer in the client/server
model as specified in [ITU] ITU G.805 & G.809. The Client layer
service access the server layer at the access point address.
5. Use Cases
PWE3 defines the signaling and encapsulation techniques for
establishing SH-PWs between a pair of ultimate PEs and in the vast
majority of cases this will be sufficient. MH-PWs are a solution to
the following limitations of SH-PWs:
-i. Inter-Provider PWs: An Inter-Provider PW is a PW that
extends from a U-PE in one provider domain to a U-PE in
another provider domain. The need for interprovider PWs
arises from the desire to use a common or converged packet
interface (e.g., MPLS) between two provider domains to carry
multiple services (i.e., IP, ATM over MPLS, etc.).
It may not be possible, desirable or feasible to establish a
Martini, et al. [Page 6]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
PW control channel between the ultimate source and
destination PEs to establish an an interprovider PW, as
required for SH-PW. At a minimum PW control channel
establishment requires knowledge of and reachability to the
remote (ultimate) PE IP address. The local (ultimate) PE may
not have access to this information due to operational or
security constraints. Moreover, a SH-PW would require the
existing of a PSN tunnel between the local U-PE and the
remote U-PE. It may not be feasible or desirable to extend
contiguous PSN tunnels between U-PEs in one domain and U-PEs
in another domain for security and/or scalability reasons or
for the fact that the two domains may be using different PSN
technologies.
SH-PW setup, maintainance and forwarding procedures do not
address the various constraints encountered in a multi-
provider environment. MH-PW setup and maintainance
procedures must be designed to satisfy requirements placed
by these constraints.
An example is the inter-AS L2VPN scenario where the ultimate
PEs reside in different provider networks (ASs) and it is
the practice to MD5-key all control traffic exchanged
between two networks. Technically a SH-PW could be used but
this would require MD5-keying on ALL ultimate source and
destination PE nodes. An MH-PW allows the providers to
confine MD5 key administration to just the PW switching
points connecting the two domains.
-ii. PW Scaling Issues: There is a requirement to deploy PWs
edge to edge in large service provider networks. Such
networks typically encompass 100's or thousands of
aggregation devices at the edge, each of which would be a
PE. A single hop pseudo-wire architecture would require that
a full mesh of PSN tunnels be provisioned to allow PWs to be
established between all PEs. This is not a scalable
solution. In a network of N PEs, the SH-PW solution requires
at least N2 unidirectional PSN tunnels to be established
and managed in the newtork, and at least (2*N-2)
unidirectional PSN tunnels to be terminated on each PE. It
also requires each PE to maintain (N-1) PW signaling
adjacencies, one to every other PE in the network. Thus, in
a single provider network of 1000 PEs, the SH-PW solution
would require a minimum of one million unidirectional PSN
tunnels in the network, a minimum of 1998 unidirectional PSN
tunnels per PE, and a total of 999 PW signaling adjacencies
per PE. Interprovider PWs further aggravate this scalability
problem.
Martini, et al. [Page 7]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
If PWs are to be setup between PEs of two provider networks
with 1000 PEs each, the SH-PW solution would require a total
of 4 million unidirectional PSN tunnels in the combined
network, 3998 unidirectional PSN tunnels per PE and a total
of 1999 PW signaling adjacencies per PE.
In order to reduce the scaling problem, there is therefore a
requirement either to support a sparse mesh of PSN tunnels
and PW signaling adjacencies, or to partition the network
into a number of smaller PWE3 domains. In either case, a PW
would have to pass through more than one PSN tunnel hops
along its path.
-iii. PSN Internetworking PWE3 signaling protocols and PSN types
may differ in different provider networks. The ultimate PEs
may be connected to networks employing different PW
signaling and /or PSN protocols. In this case it is not
possible to use a SH-PW. A MH-PW with the appropriate
interworking performed at the PW switching points can enable
PW connectivity between the ultimate PEs in this scenario.
-iv. Pseudo-Wires in Access and Metro Networks Service providers
are looking to extend PWs to access and metro networks. The
prime motive is cost reduction in capital and operation
expenses. For instance, in metro networks, providers are
looking into extending PWs to next generation SONET ADMs
using MPLS mechanisms. The objective is to increase the gain
OBfrom packet statistical multiplexing at an earlier point
in the network, reducing the recurring costs of SONET
circuits or maximizing the utilization of existing SONET
infrastructure. In access and metro Ethernet networks,
providers are looking to gain advantage of MPLS mechanisms
to setup point to point Ethernet virtual circuits with
endpoints in the same or different access/metro networks.
If the SH-PW solution is to be used in these cases, every
edge access or edge metro device with PW endpoints needs to
beome a PE from the PWE3 architecture viewpoint. This
results in increaing the number of PEs in a single provider
network from 100s and 1000s to 10s of thousands, further
aggrvating the scalability problem discussed in the previous
section. In addition, if these PEs are to become part of the
same IGP domain as the rest of the provider MPLS network, a
routing scalability problem will arise.
Using the MH-PW solution, access and metro network elements
need only maintain PW signaling adjacencies with the PEs to
which they connect. They do not need PW signaling
Martini, et al. [Page 8]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
adjacencies with every other access and metro network
device. PEs in the PSN backbone in turn maintain PW
signaling adjacencies among each other. In addition, a PSN
tunnel is setup between an access element and the PE to
which it connects. Another PSN tunnel needs to be
established between every PE pair in the PSN backbone. A
MH-PW may be setup from one access network element to
another another access element with three segments: (1)
access-element - PSN PE, (2) PSN-PE to PSN-PE, and (3) PSN-
PE to access element. In this MH-PW setup, access elements
are U-PEs while PSN-PEs are S-PEs. It should be noted that
the PSN backbone can be also segmented into PWE3 domains
with more segments per PW.
6. Multi-Hop Pseudo Wire Requirements
6.1. Architecture
The following requirements apply to the architecture for MH-PWs:
-i. Client-server transparency MUST be maintained at each layer.
That is, the PW type (i.e. ATM, Ethernet, etc) MUST be
transparent to the S-PEs in the forwarding plane, except for
the functions needed for interworking PW transport over
different PSN types. (N.B: I added the last two sentences,
but I still do not like the wording here
suggest the following:) S-PEs MAY only support switching
PWs of the same type. In this case, the PW type is
transparent to the S-PE in the forwarding plane, except for
functions needed to provide for interworking between
different PSN technologies.
-ii. If MH-PWs are tunneled, using a PSN tunnel overlay, across a
SH-PW PSN, then only the requirements of [PWE3-REQ] apply to
the SH-PW PSN. The fact that the overlay is carrying MH-PWs
MUST be transparent to the routers in the SH-PW PSN.
-iii. The PWs MUST be transparent to the P-routers. A P-router is
not an S-PE or an U-PE from the MH-PW architecture
viewpoint. P-routers provide transparaent PSN transport for
PWs.
-iv. The MH-PWs MUST use the same encapsulation modes specified
for SH-PWs.
Martini, et al. [Page 9]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
-v. S-PEs MAY change the type or encapsulation mode of a PW.
This enables the establishment of a MH-PW between two PEs
with different encapsulation capability.
-vi. A MH-PW SHOULD be able to pass across PSNs of all
technologies specified by PWE3 for SH-PWs. When crossing
from one PSN technology to another, an S-PE must provide the
necessary interowrking functions.
6.2. Traffic Engineering
The following requirements apply to the traffic engineering of MH-
PWs:
-i. Upon setting us a pseudowire, S-PEs and U-PEs MUST be able
to perform admission control for the PW over the PSN to
ensure that PW bandwidth and QoS requirements can be
satisfied. Since the PW is tunneled in a PSN tunnel, the PW
must be admitted at tunnel ingress in the direction of
traffic. Restrictions may apply depending on the PSN tunnel
types.
-ii. When seitting up a MH-PW, S-PEs and U-PEs MUST be able to
select a path across the PSN that satisfies the MH-PW QoS
and bandwidth requirements. Restrictions may apply depending
on the method used for setting up a PW segment and on PSN
tunnel types.
-iii. Bandwidth SHOULD be reserved in the PSN during the PW
routing phase to support the bandwidth requirements of the
MH-PW and keep to track of available resources.
-iv. Mechanisms to protect a MH-PW when an S-PE fails MUST be
provided.
6.3. Quality of Service
Pseudo wires are intended to support services (e.g., TDM and ATM)
which may have strict per-connection Quality of Service requirements.
This may include either absolute or relative guarantees on packet
loss, delay, and jitter. These guarantees are in part delivered by
reserving sufficient network resources (e.g. BW), and by providing
appropriate per-packet treatment (e.g. scheduling priority and drop
precedence) at queueing points.
In SH-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be
Martini, et al. [Page 10]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
used to ensure that sufficient resources are reserved in the P-
routers to provide QoS to PWs on the tunnel. In this case, resource
management (e.g. admission control of PWs onto the PSN tunnel) MUST
occur at the ingress PE. The per-packet treatment for PWs on the P-
routers and core facring interfaces on the U-PEs will be based on the
exp bits in the MPLS tunnel header.
For MH-PWs, each S-PE maps a PW to a PSN tunnel. That is, an S-PE
decides what PW to bind to which PSN tunnel. Control over binding a
PW to a PSN tunnel must be provided. Ideally, the PSN tunnel SHOULD
have better QoS or same QoS characteristics as the carried PW.
However, in certain cases, an operator may need to bind a PW to a PSN
tunnel with nominally lower QoS characteristics.
For MH-PWs, each S-PE may represent a point of contention for
resources of the PSN tunnels. Therefore, during contention for
network resources, S-PEs should enable the appropriate QoS treatment
for packets on different PWs that are multiplexed into the same PSN
tunnel. Such treatment may be indicated, by the EXP bit values of the
packet in the tunnel header.
It must also be possible to reserve sufficient resources at each S-PE
for the PWs, and to reject attempts to establish PWs on tunnels that
do not have sufficient available resources to satisfy the QoS
requirements of existing PWs, the new PW, and other services on those
tunnels. Such a PW admission control function may reside on the S-PE,
but it may also reside outside of the S-PE. If it resides on the S-
PE, then the PW signalling protocol should enable the traffic
parameters for the PW. PW traffic parameter representations must be
the same for all types of PW. If an admission control function
resides outside of the PE, e.g. through a BW broker function, then
the PW signalling protocol may not need to signal the PW traffic
parameters.
Existing services such as ATM often associate different traffic
parameter values for each direction of a bidirectional connection. If
the PW signalling protocol signals PW traffic parameters in-band, it
MUST enable separate traffic parameter values to be specified for the
forward and reverse direction.
Martini, et al. [Page 11]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
6.4. Routing
MH-PWs MUST provide the following support national and international
connections:
-i. Inter-Area: for different metro and core routing areas.
-ii. Inter-AS: e.g. between national and international ASs.
-iii. Inter-provider: for wholesale/transit and for peering
services where the two ends of the MH-PW are in different
provider networks.
In addition, the following general routing requirements apply:
-iv. MH-PWs SHOULD be routed across multiple S-PEs without the
need to explicitly specify or configure the S-PEs that a PW
uses.
-v. Manual routing SHOULD be supported to allow diversity for
1+1 protected PWs.
6.5. Signalling
The following requirements apply to the signalling of MH-PWs:
-i. At a minimum, manual configuration or provisioning of MH-PWs
SHOULD be provided.
-ii. MH-PWs MAY be set up dynamically end-to-end with a minimal
number of OSS touches.
-iii. MH-PW signalling MUST provide clear rules and consequent
indications for successful/unsucessful setup of a MH-PW.
6.6. Operations and Maintenance (OAM)
PWE3 defines an architecture where attachment circuits are connected
across a PSN. OAM mechanisms for the attachment cicuits are defined
in the specifications for those specific technologies e.g. ITU-T
I.610 for ATM. These mechanisms enable, among other things, defects
in the network to be detected, localised and diagnosed. They also
enable such defect states to clear when a fault recovers.
The interworking of OAM mechanisms for SH-PWs between ACs and PWs is
defined in [PWE3-OAM]. These enable defect states to be propagated
across a PWE3 network following the failure and recovery from faults.
OAM mechanisms for MH-PWs MUST provide at least the same capabilities
as those for SH-PWs. In addition, it should be possible to support
both segment and end-to-end OAM mechanisms for both defect
notifications and connectivity verification in order to allow defects
Martini, et al. [Page 12]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
to be localised in a multi-hop network. That is, PW OAM segments can
be U-PE to U-PE, U-PE to S-PE, or S-PE to S-PE.
It is desirable to use existing PW OAM mechanisms for MH-PWs.
The following requirements apply to OAM for MH-PWs:
-i. MH-PW OAM SHOULD be supported end-to-end across the network.
-ii. OAM activation/deactivation SHOULD be tied to MH-PW
setup/teardown.
-iii. The MH-PW client SHOULD support a A Forward Defect Indicator
(FDI).
-iv. Single ended monitoring SHOULD be supported for both
directions of the MH-PW.
-v. MH-PW OAM SHOULD support switch over between 1+1 protected
LSPs end-to-end.
-vi. In-band monitoring SHOULD be provided both end-to-end across
the MH-PW, and on a segment (i.e. SH-PW) basis.
-vii. To avoid complex OAM interworking at the S-PE, the same PW
OAM mechanisms MUST be used on both the ingress and egress
sides of an S-PE.
-viii. At the U-PE, defect notifications must MUST be propagated
between an AC and its
associated downstream PW
-ix. At the U-PE, if ACs support directional defect
notifications, the directionality of the defect notification
must be maintained when the notification is mapped to the
PW.
-x. At the U-PE, defect notifications on a PW must be propagated
to the associated downstream AC.
-xi. At the S-PE, defect notifications on the upstream segment of
PWs must be propagated to the downstream PW segment.
-xii. At the S-PE, Upstream and downstream PW segments must use
the same PW defect notification mechanisms.
-xiii. At the S-PE, defects on an upstream PSN tunnel must be
propagated to the downstream PWs that originated on that
tunnel.
-xiv. The directionality of defect notifications must be
maintained across the S-PE.
-xv. The S-PE should be able to behave as a segment endpoint for
PW OAM mechanisms
-xvi. The S-PE should pass end to end and U-PE to U-PE PW OAM
messages transparently.
Martini, et al. [Page 13]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
7. Security Considerations
To be written later.
8. Full 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.
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.
9. 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.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Martini, et al. [Page 14]
Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004
10. Normative References
[PWE3-ARCH] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-08.txt
( work in progress ), March 2003.
[PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al.,
draft-ietf-pwe3-oam-msg-map-01.txt (work in progress), October 2004
11. Informative References
[ITUQ] ITU-T Recommendation Q.933, and Q.922 Specification for Frame Mode Basic
call control, ITU Geneva 1995
12. Informative References
None
13. Author Information
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
e-mail: lmartini@cisco.com
Matthew Bocci
Alcatel Telecom Ltd,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
e-mail: matthew.bocci@alcatel.co.uk
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
e-mail: nabil.bitar@verizon.com
Martini, et al. [Page 15]
