One document matched: draft-ouldbrahim-l2vpn-service-mediation-01.txt
Differences from draft-ouldbrahim-l2vpn-service-mediation-00.txt
L2VPN WG Hamid Ould-Brahim
Internet Draft Jeffrey Sugimoto
Expiration Date: April 2005 Elizabeth Hache
Greg Wright
Nortel Networks
Himanshu Shah
Ciena Networks
Peter Busschbach
Lucent
October 2004
Service Mediation between
Layer-2 and PWE3/L2VPN Networks
draft-ouldbrahim-l2vpn-service-mediation-01.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.
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 [RFC-2026].
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.
Abstract
Ould-Brahim, et. al 1
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
[SWALLOW-IW] describes an approach for interworking a native
ATM SPVC segment with an ATM/FR-based pseudowire. The approach
requires that an ATM edge device to encode the remote MPLS
provider edge IP address within the NSAP destination address
per call-basis, and covers mostly ATM and FRF.8 specifications.
This draft covers other scenarios where a) the native layer-2
edge doesnÆt have a priori knowledge of the remote PE IP
addresses, b) the Layer-2 Provider Edge and the layer-2 network
can be native Frame Relay (FR) using native layer-2 signaling
protocols, c) the native layer-2 network can use not only NSAP
addressing but as well E.164, X.121, or any preferred native
addressing scheme, and d) the interface between the MPLS/IP
network and native layer-2 network can be FRF.10/X.76
interface. We refer to the above problem space as "Service
Mediation" to indicate that the native layer-2 signaling is
terminated at the MPLS/IP device attached to the layer-2
network and the "mediated" service is an end-to-end connection
built from two segments: one segment is in its native layer-2
form which we denote as Native Wire (NW) established using
native layer-2 signaling protocols and the other segment is a
pseudowire (PW) established using PWE3/L2VPN signaling
protocols.
Acronyms
AGI Attachment Group Identifier
AII Attachment Individual Identifier
GID Generalized ID FEC
L2PE Layer-2 Provider Edge
L2E Layer-2 Edge Device
MPE MPLS Provider Edge
MME MPLS Mediation Edge
MI Mediation Interface
MF Mediation Function
NW Native Wire
PSN Packet Switched Network (MPLS/IP network)
SAII Source Attachment Individual Identifier
TAII Target Attachment Individual Identifier
1. Introduction
[SWALLOW-IW] describes an approach for interworking a native
ATM SPVC segment with an ATM/FR-based pseudowire. The approach
requires that an ATM edge device to encode the remote MPLS
provider edge IP address within the NSAP destination address
per call-basis, and covers mostly ATM and FRF.8 specifications.
This draft covers other scenarios where a) the native layer-2
edge doesnÆt have a priori knowledge of the remote PE IP
addresses, b) the Layer-2 Provider Edge and the layer-2 network
can be native Frame Relay (FR) using native layer-2 signaling
protocols, c) the native layer-2 network can use not only NSAP
Ould-Brahim, et al. October 2004 [Page 2]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
addressing but as well E.164, X.121, or any preferred native
addressing scheme, and d) the interface between the MPLS/IP
network and native layer-2 network can be FRF.10/X.76
interface. We refer to the above problem space as "Service
Mediation" to indicate that the native layer-2 signaling is
terminated at the MPLS/IP device attached to the layer-2
network and the "mediated" service is an end-to-end connection
built from two segments: one segment is in its native layer-2
form which we denote as Native Wire (NW) established using
native layer-2 signaling protocols and the other segment is a
pseudowire (PW) established using PWE3/L2VPN signaling
protocols.
Figure 1 describes the network reference diagram for Service
Mediation. The service provider network consists of one or
multiple native layer-2 networks attached to an MPLS network.
Examples of layer-2 networks are Frame Relay and ATM networks.
The MPLS network is composed of Provider edge devices and
internal provider devices. For the purpose of service
mediation, we partition the MPLS provider edge devices into
ôMPLS Provider Edge devicesö denoted as MPE and MPLS Mediation
Edge referred as MME devices (in the context of this document
weÆll refer to these devices as just ôMPEö and ôMMEö). MPE
connects customer sites that are attached to the MPLS network,
and MME interconnects layer-2 networks to MPLS network. Note
that MPE could as well be an MME.
Similarly, we partition the layer-2 network devices into Layer-
2 Provider Edge devices (L2PE) and Layer-2 Edge devices (L2E).
L2PE are layer-2 switches attaching customer sites and L2E are
layer-2 devices that are attached to MME via an Interface
referred as a Mediation Interface (MI). Examples of mediation
interfaces are FRF.10/X.76, PNNI, AINI, etc. Note that an L2E
can as well be an L2PE.
+---+ +----+ +---+ +---+ +---+ +---+
|CE1|--|L2PE|-( layer-2)-|L2E|-<MI>-|MME|(Backbone)-|MPE|-|CE2|
+---+ +----+ ( network) +---+ +---+ MPLS +---+ +---+
{MI: Mediation Interface }
{MME: MPLS Mediation Edge }
{L2PE: Layer-2 Provider Edge }
{L2E: Layer-2 Edge }
{MPE: MPLS Provider Edge }
{CE: Customer Edge }
Figure 1: Service Mediation Network Reference
We propose to model the native layer-2 network as a layer-2 VPN
which is assigned a globally unique identifier within the MPLS
Ould-Brahim, et al. October 2004 [Page 3]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
network (i.e., VPN-ID, AGI, etc). The MPLS network is modeled
as a layer-2 host with one or multiple layer-2-based addresses.
2. Requirements
The following list represents the minimum set of requirements
for supporting service mediation. Note that some of the
requirements of this list are taken from [SM-SCOPE-REQ].
. Single solution that supports both native Ethernet, Frame
Relay and ATM layer-2 networks where an L2PE and MPE
Attachment circuits can be FR, ATM, or Ethernet.
. Should be flexible to support multiple layer-2 network
deployment scenarios with no impact on customer layer-2
signaling and routing protocols. Examples of scenarios are
Frame Relay running on top of an ATM network using FRF.8,
Frame relay network with X.76/FRF.10 network interfaces
and using E.164 or X.121 addressing plans, ATM PNNI
networks attaching to MPLS core network, ATM networks
attaching through an AINI interface, etc.
. Ability to establish dynamic end-to-end mediated
connection from a layer-2 network to the MPLS network and
from the MPLS network to the layer-2 network.
. Does not require per call configuration at the MME and L2E
levels.
. Accommodates (though not limited to) the case where the
provider encodes the remote MPE IP address within the
native layer-2 destination address per call-basis as
described in [SWALLOW-IW] (this case applies to layer-2
connections established using ATM NSAP addresses).
. Should provide as an option the ability for the MME to
discover dynamically the set of endpoints to be mediated
across the MPLS network. (i.e., the architecture should
support single-sided provisioning model with discovery).
. It is proposed that "vanilla" [PWE3-CONTROL] and IETF
L2VPN protocols can be used as the base protocols for
service mediation on the MPLS network side.
. It is proposed that PWE3 encapsulation methods can be used
for service mediation (with no changes to existing PWE3
standards).
. Does not require L2E, L2PE, MPEs and internal MPLS core
nodes to be aware of the Mediation Function (i.e., only
the MME implements the Mediation Function).
Ould-Brahim, et al. October 2004 [Page 4]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
. Supports resiliency under multiple failure conditions
requiring no operator intervention (e.g., allows the
layer-2 network to select dynamically a different MME in
case the primary MI/MME/L2E fails, or the MPLS and/or the
layer-2 networks experience a network failure, etc).
. Supports scenarios where the layer-2 connection is
established between disparate service endpoint types such
as FR or ATM to Ethernet endpoints on the MPLS network.
The dataplane encapsulation should be based on
"Multiservice Interworking IAs".
. Must be scalable so that it can support large networks with
very large numbers of connections.
. The MPE and MME should agree on an encapsulation method
either through signaling (as in negotiation) or through
manual configuration.
. Should meet the QoS requirements of the mediated native
layer-2 connection.
1.2 Network Reachability and Planning
In order for the layer-2 signaling to reach the set of MMEs,
the MPLS network needs to be reachable from the layer-2
network. This is accomplished by provisioning layer-2 prefix
addresses routable within the layer-2 network. For ATM, NSAP
summary addresses are configured at the edge device (L2E in the
case of AINI/UNI, MPLS Mediation Edge ûMME, in the case of
PNNI). The layer-2 network (L2PE) has a view of which MME node
it can reach. The prefix address could represent the entire
MPLS domain, or distinct network regions or specific nodes
(MPEs).
In the case of Frame Relay (besides the use of FRF.8),
destination nodes, distinct network regions, or even the entire
MPLS network can be assigned standard layer-2 addresses of
X.121 or E.164 addressing plans. The prefix address relates to
the FRF.10 interface point (when such interface is used). A
possible mechanism for routing Frame Relay calls to the MMEs
within the Frame Relay network is to use hunt group servers.
Hunt group servers are actually assigned the appropriate prefix
address for the MPLS region to which they will direct the
calls. As a result when the frame relay call is initiated in
the layer-2 network the call is routed to the hunt group
servers which will pass it along to one of the FRF.10
interfaces (MME).
In the case of calls originating from the MPLS network, the set
of MMEs need to be reachable from the MPLS network and more
precisely from the set of MPEs. The MPEs can be configured (or
Ould-Brahim, et al. October 2004 [Page 5]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
auto-discovered) with a list of potential MME IP addresses to
use. An MPE that intends to place a call (in this case an LSP
through sending the Label Mapping) will select a particular MME
given a local policy.
2. Endpoint Identification and Association
Since the endpoints of a mediated service are in most cases
different, we propose in this architecture to use the
Generalized ID style signaling to setup the pseudowire within
the MPLS network as described in [PWE-CONTROL] and [L2VPN-SIG].
The forwarder identifier on the MPE is known as Attachment
Individual Identifier (AII), and the signaling protocol carries
both a "Source Attachment Individual Identifier" (SAII)
representing the identifier of the local forwarder and a Target
Attachment Individual Identifier (TAII) identifying the target
forwarder and a common part represented by the Attachment Group
Identifier (AGI).
The AGI uniquely identifies the native layer-2 network (or
region thereof) within the MPLS network. One can built the AGI
from a VPN-ID format taken from RFC2685 or from other
mechanisms such as RFC2547 that guarantees its uniqueness
within the MPLS network. The network operator may choose to
associate a unique AGI per layer-2 network type, or per layer-2
network region. The AGI must represent unique layer-2 network
(or region thereof).
To setup a mediated service, the signaling protocols and the
mediation function must be able to associate the Forwarder at
one endpoint (i.e., L2PE) with the Forwarder at the other
endpoint (i.e., MPE). This association can be accomplished as
follows: On one end of the spectrum, layer-2 calls originating
from the layer-2 network will encode information that exactly
identifies the target forwarder and the destination MPE in the
MPLS network. In this scenario the forwarder located on the MPE
side will be identified using layer-2 related information (such
as port number VPI.VCI, DLCI values) and the called layer-2
address on layer-2 network must contain the IP address of the
destination MPE. We refer to this scenario as the "unmapped
mode". This model is described in detail in [SWALLOW-IW].
On the other end of the spectrum, the layer-2 calls will carry
information that maps to one or many target forwarder
identifiers with their associated MPE addresses. These
identifiers may have no relationship to the layer-2 network. We
refer to this model as the "mapped mode" to indicate that a
mapping function is required at the MME to resolve the actual
destination endpoints during the signaling phase.
Ould-Brahim, et al. October 2004 [Page 6]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
3. Unmapped Mode
The unmapped mode describes a function on the MME that derives
the TAII and the destination IP address exclusively from the
layer 2 signaling information.
The Unmapped mode, proposed and described in details in
[SWALLOW-IW], requires that the forwarder identifiers at the
MPE and the IP address of the MPE are taken exclusively from
the layer-2 information carried within the native layer-2 call
originated from the layer-2 network. In this model, the source
attachment identifiers (SAII) on the MPE must represent
information relevant to the layer-2 network being mediated.
In this mode, the native layer-2 address represented by the
Called Party Number (in this case the ATM NSAP address) encodes
the IP address of the destination MPE and is assigned a
specific address format code that indicates that this address
contains an IP address.
During the signaling phase the mediation function will screen
the Called Party Information Elements and extracts the IP
address of the destination MPE, the port number and the VPI.VCI
values. [SWALLOW-IW] suggests the use of an AFI (Address Format
Indicator) of 35 and an ICP (Internet Code Point) of 0002. The
MME screens the AFI and ICP from the received call, extracts
the IP address representing the loopback address of the
destination MPE and establishes a pseudowire to that MPE. The
TAII is exclusively constructed from the information carried
within the NSAP address (in this case the ESI ûEnd System
Identifier) and the SPVC IE (VPI.VCI/DLCI values).
Since the unmapped mode requires that the L2PE and more
precisely the called address to have prior knowledge of the IP
address of the destination MPE, it results that with the
unmapped mode an auto-discovery mechanism is not needed. Since
as well the information carried within the Called Party
information elements is enough to construct both the IP address
of the destination MPE and the TAII, no lookup is necessary at
the MME to build the signaling information destined to MPE.
However, in the unmapped mode any changes to MPE addressing
require reconfiguration of all L2PE having layer-2 connections
destined to that MPE. It is not as well possible for this mode
to support address mobility where forwarder identifiers on the
MPE need to be moved from one port to another, one MPE to
another without reconfiguring all the L2PEs having layer-2
connections destined to that MPE.
4. Mapped Mode
The mapped mode does not require the L2PE and the native layer-
2 destination address to encode and to have prior knowledge of
Ould-Brahim, et al. October 2004 [Page 7]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
the IP address of the MPE. This is accomplished by maintaining
at the MME level, a mapping function that resolves the
association between the information carried within the call
such as called party number and VPI.VCI/DLCI values to <SAII,
MPE-IP address> values (and vice versa). Such mapping can be
manually provisioned at the MME or dynamically discovered. This
mode can support layer-2 calls carrying a variety of addressing
plans (such as E.164, NSAP, X.121, etc.).
It results that in the mapped mode, the layer-2 connection can
use any available addressing plan without encoding an IP
address in the destination native address. The forwarder
identifiers on the MPE can be identified using any bit string
values that may have no relationship to the layer-2 network. An
example of forwarder identifier in the mapped mode is "Sally's
Bakery", or "NSAP123456789" or "VPI10.VCI100", "E.164/234567",
etc.
Prior to establishing a layer-2 connection that is to be
mediated across an MPLS network, an auto-discovery mechanism
can be used to reduce the information provisioned on the MME
(i.e., an auto-discovery eliminates the need for the MME to be
configured with a list of MPEs that have. attachment circuit
identifiers intended to be used for mediation purposes). The
use of an auto-discovery mechanism in the proposed architecture
allows the following key network values to be supported:
a) Any configuration changes to MPE IP addressing does not
require configuration changes to the layer 2 network
connections.
b) The Provider to support service endpoint mobility of
the layer-2 endpoints residing on the MPLS core network
(as long as the forwarder identifiers remains unchanged).
c) The MME to dynamically learn the set of remote
endpoints with their MPE IP addresses.
An example of an auto-discovery that can be used is described
in [VPN-AUTO-DISCOVERY]. In this mechanism, the auto-discovery
proceeds by having each MPE distributing its set of AII tuples
with itself as the BGP next hop and with a set of export route
target values. In most common scenarios the MMEs and MPEs will
be clients of a set of BGP route reflectors which will
distribute L2VPN information to them. The MMEs are configured
with an import policy that imports NLRIs containing attachment
identifiers that are intended to be mediated. Once the
information is received, each MME will record the actual IP
address of the remote MPE and its related set of attachment
circuits.
It may happen that the MPE would want to advertise to the MME a
pool of attachment identifiers instead of advertising each
individual attachment identifier. In this scenario, the auto-
Ould-Brahim, et al. October 2004 [Page 8]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
discovery will carry pool identifiers representing a grouping
of attachment identifiers that are intended to be mediated.
Depending on the service being mediated, the pool identifier
can be a bit string value representing an NSAP prefix (for the
case of ATM), an E-164/X.121 prefix (for the case of Farme
Relay), or just any bit string value. The pool id MUST be
unique within the layer-2 network.
An L2PE that intends to establish a mediated layer-2 connection
will initiate a layer-2 connection SETUP (using native layer-2
signaling protocol) destined to the remote attachment circuit
(or remote MPE). Note that no special knowledge is required at
the L2PE regarding the mediated nature of the service.
The call is then routed to the L2E and subsequently to the MPLS
Mediation device (MME) which will screen the layer-2
information carried within the SETUP message and performs
normal layer-2 functions (e.g., CAC, QoS, etc) at the MI.
If these functions fail the call is cleared. If not the MME
will screen for ATM calls the Called Party Number and
particularly the AFI and ICP values. If the AFI and ICP values
indicate values of "35" and "0002" then the called party number
encodes the IP address of the destination MPE. The mediation
function will then operate using the unmapped mode. The MME
extract the ESI value and combines it with information from the
SPVC IE to construct the TAII (see [SWALLOW-IW]).
For calls that do not encode an IP address in their Called
Party Number, the mapping function is based on the Called Party
information which must correspond one to one to the target
attachment identifier (or pool identifier). In this case, the
operator will need to associate for each forwarder identifier
on the MPE (SAII) its corresponding called layer-2 destination
address and its associated VPI.VCI/DLCI values. The MME is
provided (through configuration or through the use of an auto-
discovery mechanism) with the SAII and MPE IP address (and in
the case of pool style advertisement, the MME is provided with
a pool identifier and MPE IP address).
During call processing, the MME will screen the called party
number and SPVC information element and performs a best match
with the SAII (or pool identifier) and locate the destination
MPE IP address. If an entry is found, then the MME extracts the
<SAII (or POOL_ID), MPE_IP address> from the mapping table and
establishes a targeted LDP session to the remote MPE if one
does not already exist. If the MME is given a priori (through
configuration or other means) a specific TAII to use during
signaling in the MPLS network, then that TAII will be used in
the Label mapping message.
Once the reverse label mapping is received from the MPE, the
MME will format a native layer-2 connect/accept message
Ould-Brahim, et al. October 2004 [Page 9]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
destined to the remote L2PE and the end to end layer-2
connection is established.
4.1 Alternative Signaling and Endpoint Association: Special Case
In most cases and scenarios, the MPE is given only the SAII,
and the L2PE is given the "calling" and "called" information in
their native form. That information is enough to establish the
end-to-end mediated service.
If the forwarder identifier on the MPE is structured based on
called party information (such as the approached described in
the previous section), then the mapping function will screen
the called party, match it to the SAII and locate the
destination MPE IP address in order to process the call to the
MPLS network.
In the case where the forwarder identifier on the MPE has no
relation to the called address such as a bit string like
"Sally's bakery", the MME would have to associate the called
address to the actual SAII. This approach requires a
configuration of an additional specific layer-2 called party
information (be it an address, or an address with its
VPI.VCI/DLCI values) per each forwarder identifier on the MPE.
During signaling the MME will screen the called party
information, and match it to the stored called party
information, if an entry is found, then the MME extracts the
<SAII, MPE_IP address> from the mapping table.
It may happen that the MPE is given the TAII and the SAII where
the TAII is structured according to native Calling Party
information. In that case, it is possible to use the TAII to
perform the association between the native call and the
destination MPE. Note that this is special case of deployment.
In this case, when the layer-2 call reaches the MME, the MME
extracts the Calling Party and use it to look up the mapping
table in order to identify the destination <TAII, IP address to
use>. If a match is found, the MME will establish a pseudowire
to the destination MPE with a TAII equals to the SAII
attachment identifier configured on or distributed by MPE.
This approach keeps the relevancy of layer-2 related
information such as called party number including the
VPI.VCI/DLCI values, only to the layer-2 network, and it
decouples the actual called party information from the set of
MPE forwarder information on the MPLS network. The Called Party
information is only required to represent information about
reaching the MPLS network through a given set of MMEs. It is
possible (though not required) that all mediated connection
from a given layer 2 network (or layer-2 network region) to
Ould-Brahim, et al. October 2004 [Page 10]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
have the same Called Party information, all what is required is
the L2PE to have distinct Calling Party information.
5. Resiliency
In case of failure of the MI, L2E, or MME, the call is cleared
and a new call is rerouted to an alternate MME, which will
process the call according to steps described in the signaling
section.
In the case of ATM, automatic rerouting of connections upon
network failures can be achieved by PNNI with the primary and
secondary MME configured with the same NSAP summary address. As
long as a suitable path exists between the calling PNNI node
and the alternate MME node, PNNI can recover from any link or
node failure in order to complete the call to the MME.
In the case of AINI, similar rerouting mechanism can be used.
If AINI link fails then the summary address provisioned against
the AINI link is withdrawn from the PNNI network. Alternate
MMEs can be provisioned with summary addresses to provide
redundancy capabilities.
In the case of Frame Relay, the layer-2 network will have to
select an alternate FRF.10 interface. If hunt group servers are
used within the layer-2 network and in the scenario that a
particular FRF.10 interface (to the MME) becomes unavailable,
the hunt group server will be notified of the failure and a new
call will be routed to an alternate MME.
For calls originating from the MPLS network, a failure of the
MME will cause a global repair of the mediated connection. In
this case, the initial layer-2 call is cleared and the service
label is released. The MPE will then selects an alternate MME
based on some internal policy such as the proximity (select the
closest MME), or availability (selects the one that is
available), or in rotary mode, or based on some predefined MME
preferences, etc.
5.1 Service Resiliency
In the context of service resiliency, a primary attachment
circuit can be associated with one or many backup attachment
circuits. The backup attachment circuits can be on the same or
different MPE than the primary. The primary and backup
attachment circuit identifiers are unique within the AGI.
The MME will build a mapping table of <primary AII, {Backup
AIIs}>. That association can be made through configuration at
the MME or through a discovery mechanism. This table can be
Ould-Brahim, et al. October 2004 [Page 11]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
populated from the auto-discovery mechanism or can be locally
configured.
The mapping table with backups can be used in failure
situations. For example, the MME may have a local policy that
indicates that upon receiving a status from the remote MPE that
indicates failure of the primary attachment circuit, the MME
initiates a new pseudowire to the backup attachment circuit.
The approach allows service resiliency with multiple backup
attachment circuits. A primary attachment circuit may be
associated with a number of backup attachment circuits. If for
example a primary fails and a first backup is activated, a
failure of the first backup may trigger another pseudowire to
be established to the second backup, and so on. Note as well
that when the primary attachment circuit recovers, the MME may
decide to terminate the backup connection and reestablishes the
mediated connection back to the primary with no operator
intervention (if desired).
Note that there is no restriction on the type of backup
identifier to be used or the service type of the backup. An ATM
VC port can be backed up by an Ethernet VLAN or an Ethernet
port.
How the MME selects which backup to use can be a local policy
at the MME or can be guided by information advertised by each
backup MPE. For example each backup attachment circuit will
indicate its preference level.
Upon failure of the primary attachment circuit (or the primary
MPE) the MME may decide to clear the layer-2 call and
subsequent calls will be directed to the backup attachment
circuit (we refer to this scenario as global repair approach).
Another option is the MME decides to perform a local repair and
establishes a pseudowire to the backup attachment circuit
without impacting the layer-2 connection established on the
layer-2 network.
6. Security Considerations
This draft does not introduce any new security considerations
to [L2VPN-SIG] or [PWE3-CONTROL].
7. References
[SWALLOW-IW] Swallow draft ôSoft Permanent Virtual Circuit
Interworking between PWE3 and ATMö, draft-swallow-pwe3-spvc-iw-
00.txt draft-swallow-pwe3-spvc-iw-00.txt
[PWE3-CONTROL] Martini, L., et al., ôPseudowire Setup and
Maintenance using LDPö, draft-ietf-pwe3-control-protocol-
05.txt, December 2003
Ould-Brahim, et al. October 2004 [Page 12]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
[L2VPN-SIG] Rosen, E., Radoaca, V., ôProvisioning Models and
Endpoint Identifiers in L2VPN Signalingö, draft-ietf-l2vpn-
signaling-00.txt
[VPN-AUTO-DISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter, Y.,
ôUsing BGP as an Auto-Discovery Mechanism for Provider-
Provisioned VPNsö, draft-ietf-l3vpn-bgpvpn-auto-00.txt .
[SM-SCOPE-REQ] "Service Mediation scope and requirements",
mpls forum baseline text, 2004.
[SHAH-QOS] Shah, H., Ould-Brahim, H., Metz, C., "QoS Signalling
for PWE3", draft-shah-pwe3-pw-qos-signaling-00.txt, work in
progress.
8. Author's Addresses
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortelnetworks.com
Jeffrey Sugimoto
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Email: sugimoto@nortelnetworks.com
Elizabeth Hache
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Email: hache@nortelnetworks.com
Greg Wright
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Email: gwright@nortelnetworks.com
Himanshu Shah
35 Nagog Park,
Acton, MA 01720
Ould-Brahim, et al. October 2004 [Page 13]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004
Email: hshah@ciena.com
Peter Busschbach
Lucent Technologies
67 Whippany Rd
Whippany, NJ 07981
Phone: 973-386-8244
email: busschbach@lucent.com
Ould-Brahim, et al. July 2004 [Page 14]
draft-ouldbrahim-l2vpn-service-mediation-01.txt October 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 IETF's procedures with respect to rights in
IETF 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.
Copyright Statement
"Copyright (C) The Internet Society (year). 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."
Ould-Brahim, et al. October 2004 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 08:11:02 |