One document matched: draft-ouldbrahim-l2vpn-service-mediation-00.txt
L2VPN WG Hamid Ould-Brahim
Internet Draft Jeffrey Sugimoto
Expiration Date: December 2004 Elizabeth Hache
Greg Wright
Nortel Networks
Himanshu Shah
Ciena Networks
Peter Busschbach
Lucent
July 2004
Service Mediation
between
Layer-2 and IP/MPLS Networks
draft-ouldbrahim-l2vpn-service-mediation-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.
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-00.txt July 2004
Consider the scenario where the service provider establishes an
end-to-end connection between edge devices that are attached to
native layer-2 network and MPLS edge devices that are attached
to MPLS core network. The end-to-end layer-2 connection is
built from two segments: one segment is in its native layer-2
form established using native layer-2 signaling protocols and
the other segment is a pseudowire established using L2VPN/PWE3
signaling protocols. We call such scenario "Service Mediation"
and the end-to-end layer-2 connection a "mediated" service.
This draft describes a flexible service mediation architecture
that supports a number of capabilities such as address
independence, address mobility, service and mediation gateway
resiliency, support for multiple layer-2 addressing plans
(E.164, X.121, NSAP addressing, etc), ability to not only
initiate the mediated connection from the layer-2 network but
as well from the MPLS network if desired. We highlight key
components such as signaling, auto-discovery, endpoint
identification, and resiliency.
Acronyms
AGI Attachment Group Identifier
AII Attachment Individual Identifier
CIP CallIng Party
CDP CalleD Party
GID Generalized ID FEC
IE Information Element
L2PE Layer-2 Provider Edge
L2E Layer-2 Edge Device
MPE MPLS Provider Edge
MME MPLS Mediation Edge
MI Mediation Interface
MF Mediation Function
PSN Packet Switched Network (MPLS network)
SAI Source Attachment Identifier
SAII Source Attachment Individual Identifier
TAI Target Attachment Identifier
TAII Target Attachment Individual Identifier
1. Introduction
This draft outlines an architecture for service mediation
between layer-2 and MPLS networks. Service mediation addresses
network scenarios where a layer-2 connection is established
between edge devices that are attached to native layer-2
network and MPLS edge devices that are attached to MPLS core
network. The end-to-end layer-2 connection is built from two
segments: one segment is in its native layer-2 form established
using native layer-2 signaling and the other segment is an
MPLS-based pseudowire using standard-based PWE3 signaling
protocols.
Ould-Brahim, et al. July 2004 [Page 2]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
We call such service a ômediatedö service to indicate that the
native layer-2 signaling is terminated at the MPLS device
attached to the layer-2 network (which we refer as MPLS
Mediation Edge -MME) and a second segment of the layer-2
connection is established using MPLS-based PWE3 signaling
across the MPLS network.
We propose in this document an architecture that describes a
number of components and scenarios such as:
o Ability to establish dynamic end-to-end mediated
connection from a layer-2 network to the MPLS network.
o Ability to establish dynamic end-to-end mediated
connections from the MPLS network to the layer-2
network.
o Complete address independence that enables flexible
addressing of the mediated connection endpoints.
o Accommodates both native Frame Relay and ATM circuits
and addressing plans.
o Enables address mobility on either the layer-2 and MPLS
networks.
o Support of multiple aspects of resiliency such as
mediation gateway resiliency and service resiliency.
One of the goals of this draft is to support service mediation
for a variety of network deployment scenarios. Examples of
scenarios can be frame relay running on top of an ATM network,
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.
Similar problem space has been addressed in [SWALLOW-IW] which
describes an approach for interworking a native ATM SPVC
segment with an ATM/FR-based pseudowire. [SWALLOW-IW] 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 accommodates [SWALLOW-IW] model and covers scenarios
where a) the Layer-2 Provider Edge (e.g., ATM or FR switches)
can use not only NSAP addresses but as well E.164 and X.121
addressing plans, b) the native layer-2 edge doesnÆt have a
priori knowledge of the remote MPLS PE IP addresses, c) the
interface between the MPLS and native layer-2 network can be
Ould-Brahim, et al. July 2004 [Page 3]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
FRF.10/X.76 interface, d) the MPLS network can use attachment
circuit identifiers that have no relation to the layer-2
network, and e) the MPLS network can initiate mediated layer-2
connections to the native layer-2 network.
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
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.
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].
Furthermore, we describe how an auto-discovery mechanism can be
Ould-Brahim, et al. July 2004 [Page 4]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
integrated and used to scale the architecture to support as
large number of mediated connections.
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
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
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). We propose a number of ways in which this
association can be accomplished:
- 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
Ould-Brahim, et al. July 2004 [Page 5]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
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". An example of 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.
The unmapped and mapped modes will be discussed in detail in
the next sections.
2.1 How are the Mediated Endpoints identified in the MPLS network?
Since we propose to use the Generalized ID FEC element
described in [PWE3-CONTROL], the forwarder identifier on the
MPE is known as Attachment Individual Identifier (AII). 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).
In this architecture, all forwarder identification options
described in [PWE3-CONTROL] or [L2VPN-SIG] can all be used.
2.2 How are the layer-2 Endpoints identified in the Layer-2
Network?
With respect to the layer-2 network, the layer-2 connection is
established via signaling messages between a CallIng Party
(CIP) and a CalleD Party (CDP) forwarders. As an example, the
messages between the CIP and the CDP will include information
such as Calling and/or Called Party Numbers and for ATM an SPVC
IE to identify individual circuits (i.e. VPI.VCI).
Note that existing methods and procedures currently used in
layer-2 networks to identify layer-2 endpoints can all be used.
Ould-Brahim, et al. July 2004 [Page 6]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
For mediated connections in the L2 to MPLS direction, the CIP
and/or CDP may encode sufficient information to construct the
TAII and determines the IP address of the MPE or may contain
information that will map to specific TAII and the IP address
of the MPE. For calls originating from the MPLS network the
TAII may encode information used to construct the CDP of a
given L2PE.
2.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 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.
The unmapped mode described in [SWALLOW-IW] proposes that 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).
2.3.1 Characteristics of the Unmapped Mode
The unmapped mode presents the following characteristics:
- Auto-discovery and MME lookup: 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
Ould-Brahim, et al. July 2004 [Page 7]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
address of the destination MPE and the TAII, no lookup
is necessary at the MME to build the signaling
information destined to MPE.
- Address independence: The unmapped mode does not provide
address independence since the layer-2 addresses for the
called end must encode an IP address of the destination
MPE. It results that any changes to MPE addressing
require reconfiguration of all the layer-2 connections
destined to that MPE.
- Endpoint identification: The forwarder identifiers on
the MPLS network are taken exclusively from the layer-2
information.
- Addressing plans: Currently defined solutions support
only the NSAP-based ATM addressing plan.
- Service resiliency: It is not possible for this model to
support a network mediation scenario where backup
attachment identifiers (located on different MPEs) are
used for cases where primary pseudowire fails, or MPE
failures.
- Address mobility: It is not as well possible for this
mode to support address mobility. Forwarder identifiers
on the MPE cannot be moved from one port to another, one
MPE to another without reconfiguring all the layer-2
connections on the layer-2 network.
2.4 Mapped Mode
In order to support flexible addressing, address independence,
address mobility and service resiliency, the architecture needs
to:
a) Decouple the forwarder identifiers on the MPE from the
actual layer-2 type of service being mediated.
b) Decouple the layer-2 Called Party Information elements
from the actual IP address of the destination MPE.
c) Provide at the MME level, a mapping function that
resolves/translates between the Calling/Called Party
information elements to the actual SAII values.
We refer to the architecture functionality that meets the above
points as the "Mapped mode".
The mapped mode does not impose on the L2PE and the native
layer-2 address to encode and to have prior knowledge of the IP
address of the MPE and thus this model can support addressing
plans other than ATM NSAP and can make use of an auto-discovery
mechanism.
Ould-Brahim, et al. July 2004 [Page 8]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
The forwarder identifiers on the MPE are 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.
2.4.1 Characteristics of the Mapped Mode
The mapped mode presents the following characteristics:
- Auto-discovery and MME lookup: The mapped mode requires
a mapping function at the MME that resolves the
association between Calling/Called Party to <SAII, MPE-
IP address> values (and vice versa). Such mapping can be
provisioned at the MME or dynamically established \
(either through the use of an auto-discovery mechanism
or during signaling phase). We describe in the next
sections two approaches on how this mapping can be
accomplished.
- Address independence: Does not mandate the called layer-
2 address to encode MPE IP address.
- Endpoint identification: Allows flexible endpoint
identification. The MPE can assign forwarder identifiers
that are not related to the layer-2 network. Note that
flexible forwarder identification allows flexible
migration scenarios. For example, an ATM port on the MPE
can be upgraded to an Ethernet port performing service
interworking function without requiring changes to both
the forwarder identifiers on the MPE and the layer-2
endpoints on the layer-2 networks.
- Addressing plans: Allows the layer-2 addresses (calling
or called) to be of any addressing plans (such as E.164,
NSAP, X.121, etc.).
- Service resiliency: It may be desired that a particular
forwarder identifier to be backed up by one or many
backup attachment identifiers configured on the same or
different MPEs. In case the primary forwarder fails the
MME will establish an alternate pseudowire to the backup
attachment identifier. The mapped mode can support such
scenario by allowing the MME to select <Backup SAII,
Backup MPE IP address> during failure situations. In the
resiliency section we describe an approach on how the
backup mechanism can be used without requiring
configuration at MPE and MME of the association between
<primary, and backup>.
- Service mobility: Due to the decoupling of the forwarder
identification from the MPE, the mapped mode support the
ability to move a mediated endpoint from one port to
Ould-Brahim, et al. July 2004 [Page 9]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
another, from one MPE to another without requiring
reconfiguration of the layer-2 connections at the layer-
2 network.
2.4.2 How does the Mapping Function Operate?
The mapping function can be based on the Calling Party
Information or the Called Party information.
2.4.2.1 Called-based Mapped Mode
In the case of a mapping based on Called Party information, the
Called Party must correspond one to one to the target
attachment 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.
One approach would be to structure the forwarder identifier on
the MPE side based on the called party information. For example
the SAII will encode a layer-2 address concatenated with
VPI.VCI/DLCI values. In this case, 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.
Another approach will be to configure a forwarder on the MPE
that has no relation to the called address such as "Sally's
bakery". In this case a separate called party information such
as NSAP=123456 and VPI.VCI=40.30 (at MPE or MME) needs to be
configured that corresponds to the TAII (advertised as SAII by
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. This approach is
cumbersome to operate as it 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.
2.4.2.2 Calling-based Mapped Mode
As indicated in the previous section, when forwarder identifier
on the MPE have no relation to the layer-2 network, the called-
based approach requires the layer-2 call to encode a specific
called party information (called party number and/or
VPI.VCI/DLCI values) that maps one to one to forwarder
identifier on the MPLS network. A more scalable approach that
removes the need for an additional called party information is
to use the Calling Party information instead of the Called
Party during the lookup procedure.
Ould-Brahim, et al. July 2004 [Page 10]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
In this approach, the MME is provided with the tuple <SAII,
TAII, MPE IP address>. This information can be configured or
distributed by the MPE using an auto-discovery mechanism where:
- The SAII (as sent by the MPE if an auto-discovery
mechanism is used) will indicate the actual forwarder
identifier on the MPE.
- The TAII indicates the actual Calling Party Information
(CIP) (can be a concatenation of Calling party number
and VPI.VCI/DLCI values) as configured on the L2PE.
When the layer-2 call reaches the MME, the MME extracts the
Calling Party (CIP) and use it to look up the mapping table in
order to identify the destination <TAII, IP address to use>.
The CIP is compared to the TAII information distributed (or
configured at the MME) by the MPE. 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 (CDP) 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
have the same Called Party information, all what is required is
the L2PE to have distinct Calling Party information.
3. Auto-Discovery
The use of an auto-discovery mechanism allows the following key
values to be supported:
a) The Provider to support service endpoint mobility of
the layer-2 endpoints residing on the MPLS core network.
b) The MME to dynamically learn the set of remote
endpoints with their MPE IP addresses.
c) The L2PE to use any native layer 2 addressing plan
without requiring synchronization between the MPLS core
network management and layer-2 network operations in terms
of address management of the MPE devices (i.e., any change
to MPE addressing, etc does not require configuration
changes to the layer 2 network connections).
d) For calls originating from the MPLS network, the MPEs
to learn dynamically the set of MMEs gateways to be used
to reach layer-2 networks.
Ould-Brahim, et al. July 2004 [Page 11]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
The framework for a BGP-based auto-discovery is described in
[VPN-AUTO-DISCOVERY]. The detailed BGP-based auto-discovery
procedures for L2VPNs are documented in [BGP-L2VPN-AD].
The auto-discovery proceeds by having each MPE distributing its
set of <SAII,TAII> 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.
For calls originating from the MPEs and destined to the layer-2
networks, the use of an auto-discovery mechanism allows the
MPEs to discover the set of MME addresses and the set of AGIs
supported within these MMEs.
4. Signaling
4.1 Layer-2 Initiated Mediated Connections
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. Note
also that the MME should be in ready state able to receive
incoming calls from the layer-2 network and will have the
following information already available:
- The list of forwarder identifiers. In this case the MME
will build a table of <SAII, TAII, MPE_IP addresses>. The
SAII is the forwarder identifier on the MPE side. The TAII
points to the Calling Party Information elements (i.e.,
combination of Calling Party Number and SPVC IE).
- The list of IP addresses of the destination MPEs
corresponding to the list of <SAII,TAII>.
For Frame Relay layer-2 network the calling and called
addresses are either of E.164 or X.121 addressing plans
(assuming FRF.8 is not used). In the case of an ATM service,
the calling and called addresses are NSAP based addresses. The
call is then routed to the L2E and subsequently to the MPLS
Mediation device (MME) which will perform the following steps
(in the following we describe only signaling procedures using
the calling-based mapped mode.):
Ould-Brahim, et al. July 2004 [Page 12]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
1. The MME 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 then the following steps are
performed.
2. 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. Detailed procedures for this mode are described
in [SWALLOW-IW].
3. For calls that do not encode an IP address in their Called
Party Number, the MME will screen the Calling Party
Information Elements such as Calling Party Number and
VPI.VCI/DLCI values. That information is compared to the
list of AIIs distributed by MPE (as SAIIs) or configured
on the MME.
4. If a match is found then the MME will locate the TAII
(which is the actual forwarder identifier on the MPE side)
and its correspondent IP address of the destination MPE.
5. The MME establishes a targeted LDP session to the remote
MPE if one does not already exist.
6. The MME will format the Generalized ID FEC TLV (GID) where
the TAII field is the forwarder identifier of the
attachment circuit on the MPE, and the SAII is built
either from the actual source address of the call, or is
taken from the list of available AII residing on the MME.
Once the GID is constructed the MME will send its label
mapping to the MPE indicating its intention to establish a
pseudowire to the TAII.
7. Upon receiving the Label Mapping, the MPE follows the
procedures described in [PWE3-CONTROL] and if the Label
Mapping is accepted it initiates a reverse label mapping
to the MME.
8. Once the label mapping is received from the MPE, the MME
will format a native layer-2 connect/accept message
destined to the remote L2PE and the end to end layer-2
connection is established.
4.2 MPLS-Initiated Mediated Services
Ould-Brahim, et al. July 2004 [Page 13]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
It may be desirable to establish a mediated service where the
MPLS network (i.e., MPEs) initiates the signaling procedures
instead of the layer-2 network. In this model of operations,
each MPE will be provided with a list of MMEs to be used for
mediation purposes. This list can be configured or auto-
discovered. Once a particular MME is selected, the MPE
establishes a targeted LDP session to that MME and initiates
the signaling procedures as follows:
1. The MPE will build the Generalized ID FEC with a TAII
that encodes the actual Called Party Number. The Called
Party Number represents the address in the layer-2
network of the L2PE endpoint.
2. The MPE will provide additional information that can be
used to construct the called VPI.VCI/DLCI values. An
option is to define a new TLV (i.e., Service Mediation
TLV) and encodes the VPI.VCI/DLCI values.
3. The MPE will as well provide sufficient information to
the MME about QoS related information of the mediated
service. An example of QoS procedures that can be used
are described in [SHAH-QOS].
4. The SAII encodes the actual forwarder identifier of the
MPE attachment circuit. That identifier can be any bit
string value. The AGI value is the same as in the Layer-
2 initiated approach and represents an identifier for
the layer-2 region. Once the Label Mapping is received
by the MME, the following procedures are performed:
5. The MME will construct the Called Party Information
Elements (CDP) from the TAII value and the VPI.VCI/DLCI
values from the Service Mediation TLV if any and the
traffic management descriptor from the QoS TLV.
6. The Calling Party Information Elements (CIP) may contain
the layer-2 prefix address or another address that is
assigned for that particular MME. The calling
VPI.VCI/DLCI values will indicate an attachment circuit
selected for this connection at the MME device. The call
is then sent to the destination L2PE which will process
the call using normal layer-2 procedures.
7. If the call is accepted the L2PE sends its connect or
accept message to the MME.
8. The MME will then initiate the reverse label mapping
destined to the remote MPE and the end-t0-end mediated
connection is established.
Ould-Brahim, et al. July 2004 [Page 14]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
5. Resiliency
5.1 MME 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.2 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}> based on the shared TAII (since the primary and backup
are configured with the same TAII). This table can be 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
Ould-Brahim, et al. July 2004 [Page 15]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
indicates failure of the primary attachment circuit, the MME
initiates a new pseudowire to the backup attachment circuit.
The architecture 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
[L2VPN-SIG] Rosen, E., Radoaca, V., ôProvisioning Models and
Endpoint Identifiers in L2VPN Signalingö, draft-ietf-l2vpn-
signaling-00.txt
Ould-Brahim, et al. July 2004 [Page 16]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
[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 .
[BGP-L2VPN-AD] Radoaca, Unbehagen, P., et al., "BGP-based
Auto-Discovery for L2VPNs", work in progress, draft-hlmu-l2vpn-
bgp-discovery-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
Email: hshah@ciena.com
Ould-Brahim, et al. July 2004 [Page 17]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
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 18]
draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004
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. July 2004 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-22 08:16:03 |