Internet DRAFT - draft-delord-pwe3-oam-applications
draft-delord-pwe3-oam-applications
Pseudo-Wire Edge-to-Edge (PWE3) Working Group Simon Delord
Internet Draft Uecomm
draft-delord-pwe3-oam-applications-02.txt
Expires April 2006 Philippe Niger
France Telecom
Yuichi Ikejiri
Yuichiro Wada
NTT
Deborah Brungard
ATT
Alain Vedrenne
Equant
Lei Zhu
Sprint
Kenji Kumaki
KDDI
Vasile Radoaca
Consultant
Dinesh Mohan
Nortel
Ali Sajassi
Cisco Systems
October 2005
PWE3 Applications & OAM Scenarios
draft-delord-pwe3-oam-applications-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79.
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.
Delord, et. al. Expires April 2006 [Page 1]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
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.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document provides requirements and a framework for PWE3 Operation
Administration and Maintenance (OAM). It extends the PWE3 architecture
reference model by including multi-segment Pseudo Wires (PWs) and also a
detailed model of the access portion of the network.
This document targets to provide applicability guidelines for the on
going OAM work by describing different implementation solutions and
detailing the Pros and Cons of each solution.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119
Table of Contents
STATUS OF THIS MEMO...................................................1
ABSTRACT..............................................................2
1. OVERVIEW...........................................................3
1.1. Terminology......................................................4
1.2. General considerations...........................................4
2. EXTENSION TO THE ARCHITECTURE REFERENCE MODEL......................6
2.1. PWE3 Architecture Reference Model................................6
2.2. Framework extension based on the access service and layered model 6
3. PWE3 OAM FRAMEWORK & REQUIREMENTS..................................8
3.1. PWE3 OAM Framework...............................................9
3.1.1. OAM Domains....................................................9
Delord, et. al. Expires April 2006 [Page 2]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
3.1.2. Propagation of information between OAM Domains.................9
3.2. PW OAM Requirements..............................................9
3.2.1. Generic Requirements..........................................10
3.2.2. Specific Requirements.........................................11
4. PWE3 APPLICATIONS & OAM SCENARIOS.................................15
4.1. Service Supervision.............................................15
4.1.1. E2E Service Supervision.......................................16
4.1.2. Segment Supervision...........................................19
4.2. Application to network scenarios................................21
4.2.1. Homogenous Services...........................................21
4.2.2. Heterogeneous Services........................................25
5. ACKNOWLEDGMENTS...................................................26
6. SECURITY CONSIDERATIONS...........................................27
7. NORMATIVE REFERENCES..............................................27
8. INFORMATIVE REFERENCES............................................27
9. FULL COPYRIGHT STATEMENT..........................................27
10. AUTHORS' ADDRESSES...............................................28
11. APPENDIXES.......................................................29
11.1. Detailed description of each layer of the model................29
11.1.1. Network Layer................................................29
11.1.2. E2E SP Layer.................................................29
11.1.3. Customer Layer...............................................31
12. IPR Notice.......................................................31
1. Overview
The purposes of this document are the following:
. extend the PWE3 architecture reference model by including a detailed
model of the multi-segment Pseudo Wire (PW) OAM
. extend the PWE3 architecture reference model by including a detailed
model of the access portion of the network
. provide additional requirements as well as a framework for PWE3
Operation Administration and Maintenance (OAM)
. to provide applicability guidelines for the on going OAM work by
describing different implementation solutions
The following documents were taken in consideration for the background
of this work:
. [L2VPN OAM FWK] provides framework and requirements for L2VPN
services
. [MH-PW Req] introduces OAM requirements for MH-PWs
Delord, et. al. Expires April 2006 [Page 3]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
. [OAM Message Mapping] specifies the mapping of defect states between
a PW and the Attachment Circuits (AC) of the end-to-end emulated
service for an homogeneous service
. [VPWS Iwk] specifies the mapping of defect states between a PW and
ACs of the end-to-end emulated service for an heterogeneous service
Additional documents that are related to this work are:
. [VCCV] which describes how to monitor the two endpoints of a SH-PW
. [MPLS OAM] which describes generic OAM procedures for MPLS networks
1.1. Terminology
This draft uses the terminology introduced in [L2VPN OAM FWK] and [PWE3
FWK]. In addition the draft introduces the following terms:
. Access Network: is defined as a network between the CE and the PE
devices that can support access services and ACs.
. AS (Access Service): This is a new concept introduced in this
document.It is defined as a transport service between the CE and the
PE devices over which ACs can be multiplexed. Its role is similar to
PSN that provides a transport service for PWs between PEs.
. E2E L2 Service: the E2E L2 service provided by the E2E SP and seen by
the end customer.
. PE SA (PE Service Aware): the PE is aware of the E2E Service and able
to process such native service PDUs.
. PE NSA (PE Non Service Aware): the PE has no knowledge of the E2E
Service.
1.2. General considerations
Different types of L2 services requiring the use of PWs are described in
[L2VPN-FRWK] and are classified under the following three categories:
. VPWS is a point-to-point service where CEs are presented with point-
to-point virtual circuits. These point-to-point services can also be
sub-classified in two types: homogeneous (End User to SP Network
Interfaces are of the same type) and heterogeneous (End User to SP
Network Interfaces are of different type).
. VPLS is a bridged LAN service provided to a set of CEs that are
members of a L2 VPN. CEs that are member of the same service instance
communicate with each other as if they are connected via a bridged
LAN.
. IPLS is a special VPLS which is used to carry only IP service
packets.
All these services rely on the use of PWs whose architecture is
described in [PWE3 Architecture]. The reference model for the network
architecture between PEs is presented in Figure 1.
Delord, et. al. Expires April 2006 [Page 4]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
native service native service
Figure 1: PWE3 Network Reference Model
In the most general case the PE is considered to be Service Aware (SA)
as the PE has some knowledge of the E2E Service. It can process native
service PDUs to implement service specific functions (for example
forwarding for VPLS service) and to encapsulate service PDUs onto the
PW. In some specific cases it could be envisaged not to process native
service PDUs at PE level, for example for point to point service (VPWS
service). In that case each PE encapsulates the access technology over
the PW to the remote PE, and is considered to be Not Service Aware
(NSA). This configuration is particularly relevant when both access
networks use the same technology.
Depending on the service purchased, the management of the CEs can fall
under the responsibility of either the SP or the customer itself.
Similarly, Figure 1 shows that the SP uses the PSN to deliver its
service but it also needs to rely on two access networks (between CE1 &
PE1 and between CE2 & PE2). The emulated service relies then at least on
three different networks that can be owned and managed by different
entities. Furthermore, the capabilities of every network device (PESA or
PENSA) may lead to specific OAM limitations (a network device not being
able to process specific OAM flows).
For all these reasons that provide a complex problem space, the Access
part needs to be accurately taken into account by extending the [PWE3
Architecture] reference model. This document introduces PWE3 OAM
framework and requirements.
Delord, et. al. Expires April 2006 [Page 5]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
2. Extension to the Architecture Reference Model
This section extends the PWE3 architecture reference model by including
a detailed model of the access portion of the network.
2.1. PWE3 Architecture Reference Model
PWE3 architecture describes the reference model presented in figure 1.
In this architecture reference model, end to end service is provided
between two CEs located in two remote customer sites. Each CE is
connected to a PE using an AC which carries native service data units.
At the PE level these native service data units are processed to
perform:
. Specific functions necessary for service delivery using a Native
Service Processing (NSP) component
. Selective forwarding of native service data units between ACs and PWs
using a Forwarder component.
Native service data units are then encapsulated within a PW for
transmission over the PSN to the remote PE, where symmetrical operations
to those described previously are performed to deliver native service
data units to the remote CE. A given PW carries data units associated to
only one service. Between PEs, PWs are generally grouped and multiplexed
in a PSN Tunnel for transparent transport over the PSN. This requires a
PW demultiplexer function as defined in [1] to provide the capacity to
deliver multiple PWs within a single PSN tunnel. This includes the
definition of a PW identifier that must be unique at least per PSN
tunnel.
The transport service provided by a PW between two PEs can alter native
service characteristics so the PW is assumed to deliver only service
emulation between its ingress/egress interfaces.
For the core network only the PSN tunnels are visible (PWs are only
processed at PE level). PSN tunnels are initiated and terminated at
ingress and egress PEs where PWs multiplexing within PSN tunnels is
achieved. PSN tunnels are processed within the PSN and provide
connectivity between PEs with the appropriate QoS characteristics
required by the transported services.
2.2. Framework extension based on the access service and layered model
Figure 2 presents the extension of the architecture reference model by
taking into account the access network.
+----+ +----+
+-----+ | PE1|==========| PE2| +-----+
| | | | | | | |
Delord, et. al. Expires April 2006 [Page 6]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
| CE1 | +---+ +---+ | | | | +---+ +---+ | CE2 |
| |--|NTU|--|NTU|-| | | |-|NTU|--|NTU|--| |
+-----+ +---+ +---+ | |==========| | +---+ +---+ +-----+
+----+ +----+
A<------------------------E2E-Customer-Service--------------------->
B1 <-----------------E2E-Service-Provider-Service--------->
B2 <--------AC--------><-----PW----------><------AC------->
C <---------> <-----------> <--------->
Access Service Transit Service Access Service
A: Customer Layer
B1: End to End Service sub-layer of the E2E Service Provider Layer
B2: Network sub-layer of the E2E Service Provider Layer
C: Network Layer
FIGURE 2: Layered Model for an E2E SP
Today, an AC is defined as the means to attach a CE to a PE, and it is
assumed that the native service available at the CE level is also
available at the ingress and egress interfaces of the PE. An AC is
defined as a physical or logical circuit attaching a CE to a PE [PWE3-
ARCH]. It is not explicitly defined as a transport mechanism for native
services between a CE and a PE as is the case for a PW between PEs.
This simplified view of the access part of the reference model is well
adapted for simple configuration, typically for a CE offering only one
service (one L2 VPN service) and in addition physically connected to a
PE by a point to point link. It is however more difficult to apply this
model to more complex configurations (e.g the CE is not directly
attached to the PE, or the E2E SP is relying on another SP for the
access part).
For these configurations it is useful to describe more precisely the
access part of the reference model.
If we consider the case of a Service Provider (called here E2E SP)
offering to customers end to end services with a national or
international coverage, the service architecture model applicable to
this kind of SP is represented in figure 2. It shows:
. customer equipments located at the entrance of each customer site
(CPE),
. SP equipments located in customer sites (CE) and in his POPs (PE),
. the Access Networks (represented as NTU edge equipments) and
. Access services used for connection of customers to POPs,
. Transit Network and Transit service used for POPs interconnection.
Delord, et. al. Expires April 2006 [Page 7]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
Figure 2 also details the different levels of service:
. end to end customer service defined between customer equipments
. service provided by the E2E SP between the customer interface of CE
equipments
. AC established between CE and PE and PW between PEs as defined in the
IETF reference model.
Figure 2 basically shows how the different elements constituting this
model can be organized in a layered approach. In this layered model two
adjacent layers are expected to have a client/server relationship
between them. Each server layer is responsible for all the
functionalities it implements to deliver the negotiated service to the
client layer: transfer of information, QoS (prioritization, policing,
shaping, etc.), signaling, OAM.
The main interest of this client/server architecture is the introduction
of some form of hierarchy in the global architecture allowing a more
precise definition of the expected role of each entity.
Another advantage is the limitation of required interworking mechanisms
between the different networks, as these mechanisms can be rather
complex particularly when the peer networks use technologies based on
different approaches (connection oriented versus connectionless
oriented).
The proposed layering presented in figure 2 is based on three distinct
layers:
. Customer layer
. E2E SP layer
. network layer
Additional layers could be introduced, particularly at the network
layer, but this would increase the complexity of the model with only
limited added value for the discussion here.
This model clearly shows the difference between an AC and an Access
Service. It also shows that if interworking can be envisaged between an
AC and a PW, this is not the case between an Access Service and a PW
without breaking the layered structure of the model.
The detailed description of these layers in presented as an Appendix.
3. PWE3 OAM Framework & Requirements
This section introduces PWE3 OAM framework and OAM requirements. This
version of the document is attempting to synchronize the PWE3 OAM
framework and requirements with the [L2VPN OAM FRMK].
Delord, et. al. Expires April 2006 [Page 8]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
3.1. PWE3 OAM Framework
TBD.
This will be based on OAM framework constructs in [L2VPN OAM FRMK].
3.1.1. OAM Domains
TBD.
As presented in figure 2 an E2E service is generally implemented using
several underlying networks, each operated by a separate
networks/service provider. Each network is composed of a set of
equipments interconnected by physical and/or logical links. It provides
services (Access or Transit services for example) and generally
implements its own supervision solution for monitoring of these
services. If supervision is based on OAM mechanisms this leads to the
definition of an OAM domain.
As for the service point of view, OAM domains can be organized in a
layered model with client/server relationship between layers. From
Figure 2 it can be seen that OAM domains can be positioned at the same
level in the layered model (adjacent domains) or at different layers
(hierarchical domains).
3.1.2. Propagation of information between OAM Domains
TBD.
This will be based on OAM framework concepts in [L2VPN OAM FRMK].
3.2. PW OAM Requirements
This section of the draft focuses on OAM requirements that are
applicable to PWs. The L2VPN service requirements are described in
[L2VPN_OAM_FWK].
A fault affecting the network can be treated using a recovery procedure
at service level resulting in a short interruption of the services
supported by the network, with a rapid return to a normal state of
operation. For example a link failure in a MPLS based network can be
recovered at service level using a back up LSP. However the fault is
still present in the network and the network provider needs additional
diagnostic tools to identify and locate the fault in order to start
recovery procedure at network layer.
Delord, et. al. Expires April 2006 [Page 9]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
3.2.1. Generic Requirements
Transfer plane mechanism: a preliminary requirement regarding OAM
mechanisms is the fact that they must be based on OAM information
carried through the network using the same path as native service data
units. OAM messages must be transported using the transfer plane not the
control plane.
OAM information containment: filtering of OAM information at the edge of
an OAM domain (MEP location) must be possible. It must be possible to
strictly contain OAM information generated in a given OAM domain inside
this domain. This implies filtering of internal OAM information to
prevent leaking outside the domain. It also implies filtering of
external OAM information to prevent injection inside the domain. It
should also be possible to configure filtering of OAM information to
allow propagation of some OAM information between domains (e.g. alarm
indication).
Client/server OAM relation: client/server relationship at the edge of an
OAM domain (MEP location) must be possible between hierarchical OAM
domains. It must be possible to configure filtering of OAM information
to allow propagation of some OAM information between hierarchical
domains (for example alarm indication). Inside a single OAM domain
client/server relationship must be possible between different layers at
MEP location. It must be possible to configure filtering of OAM
information to allow propagation of some OAM information between layers
(e.g. alarm indication between network and service layers).
Transparency to OAM flows: within one OAM domain it must be possible to
transport transparently the OAM information related to upper layer
domains. E.g. E2E SP service must be able to transport transparently end
to end customer service OAM.
Identification of OAM traffic: within an OAM domain it must be possible
to clearly distinguish OAM traffic flows from other traffic flows
without having to process the OAM message.
Identification of OAM flows: within an OAM domain it must be possible to
clearly identify a given OAM traffic flow and make an unambiguous
association with the monitored entity to which this OAM flow applies. It
must also be possible to discriminate OAM traffic flows generated inside
the domain from OAM traffic flows generated by upper layer domains in
order to guarantee transparency.
Processing of OAM flows: each device in an OAM domain must be able to
determine whether to process a given OAM message locally (MEP/MIP) or
pass it through without processing. This must be achieved using
information (like an OAM flow identifier, selective addressing of
MEP/MIP equipment, etc) located inside the header of OAM messages. The
processing for passed thru OAM flows must be the same as for normal
traffic flows within all devices. This is particularly true for
equipments that are not implementing OAM capabilities.
Delord, et. al. Expires April 2006 [Page 10]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
Bidirectional OAM flows: OAM mechanisms must allow bidirectional
exchange of OAM information, at least between peer MEPs. This
bidirectional information flows is required to allow implementation of
some OAM mechanisms, like backward alarm indication propagation,
loopback, performance monitoring, etc. Depending on the type of OAM
function it is however not always required that the return path uses the
same data path through the transfer plane as service data unit
OAM activation/deactivation must be harmonized with the set-up/tear-down
of the monitored entity.
3.2.2. Specific Requirements
This paragraph details specific OAM requirements applicable to PWs.
3.2.2.1. Connectivity Fault Detection & Verification
The OAM mechanisms must provide the availability to monitor connectivity
between two peer MEPs (for example for the E2E SP from CE to CE). This
connectivity verification must be based on OAM information carried
through the network using the same path as native service data units
(typically OAM CV messages periodically exchanged between MEPs).
Connectivity verification must provide the availability to detect a
failure of the whole service. Bidirectional connectivity verification is
achieved using a CV OAM mechanism in each direction.
In case of Loss of Connectivity (LOC) detection at the sink MEP, this
MEP must enter a not operational state for the considered Maintenance
Entity (for example end to end service). The sink MEP must generate a
backward alarm indication to the source MEP of the ME (RDI or BDI, see
below).
If the Maintenance Entity is a server layer for an upper layer client
layer it must also be possible to generate at sink MEP a forward alarm
indication to client layer (AIS/FDI see below). Upon reception of the
backward alarm indication by the source MEP, the source MEP must not
generate a backward alarm indication at client layer (this backward
alarm indication will be generated internally to the client layer by the
client sink MEP).
The principle of operation of alarm indication described here is
detailed in the following paragraph.
These alarms must be sent periodically until a normal operational state
is recovered. In all cases it should be possible to report the type of
fault affecting the service (LOC type of alarm or LOC for server layer).
It must be possible to use the CV OAM mechanism in continuous mode for
proactive monitoring and in an on demand mode for punctual verification.
Delord, et. al. Expires April 2006 [Page 11]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
In continuous mode the detection time of this connectivity verification
procedure must be configurable to match different types of application,
and to be able to provide homogenous treatment over several networks.
The detection time required for protection is in the sub-second order.
Connectivity verification mechanism should also provide the availability
to detect a misbranching or misdirection affecting only a portion of
service traffic.
In order to improve detection time it could be useful to allow MIPs to
analyse CV messages and generate LOC AIS/RDI alarm toward sink MEP.
It should be noted that CV mechanism can be used to provide information
on network or service topology, as when CV messages have been treated
each MEP has knowledge of all its peer MEPs (see below Traceroute
function).
3.2.2.2. Connectivity Fault Notification & Alarm Notification
Fault Notification is reported using alarm indication messages toward
both MEPs in forward direction (to the destination or sink MEP) and in
backward direction (to the source MEP). This two types of alarm
notification are generally referred as AIS/RDI or FDI/BDI. It is useful
to be able to report the type of fault within this alarm indication
messages.
It must be possible to propagate this alarm indication to adjacent and
hierarchical OAM domains. Within a single OAM domain it must be possible
to propagate alarm indication between Maintenance Entities located at
different layers having client/server relationships.
Within an OAM domain it must be possible to coordinate the generation of
alarm indications in order to generate only the most appropriate alarms,
in order to avoid creation of a storm of alarm indications.
It must be possible to generate periodically the alarm indication
messages as long as the fault is active. In case of return to normal
operational state, the generation of alarm messages must be stopped.
This implicitly indicates a return to a normal state of operation, no
specific message is required.
It must be possible to generate alarm indication in the following cases:
. Upon detection of a loss of connectivity (LOC): The use of alarm
indication in such case is described in the previous paragraph.
. Upon reception of a default indication from a server layer: This is
typically a transport failure indication reported by an underlying
network layer to the service layer (for example a link failure
between two equipments). The use of alarm indication in such case is
described below.
Delord, et. al. Expires April 2006 [Page 12]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
In case of default indication reported by the server layer the first
equipment (MIP/MEP) detecting the default at the service layer ME must
generate a forward alarm indication to the sink MEP (AIS/FDI). Upon
reception of the alarm indication the sink MEP must enter a not
operational state for the considered Maintenance Entity. The sink MEP
must generate a backward alarm indication (RDI/BDI) to the source MEP of
the ME.
If the service Maintenance Entity is also a server layer it must be
possible to generate at sink MEP a forward alarm indication to client
layer. Upon reception of the backward alarm indication by the service
source MEP, this source MEP must not generate a backward alarm
indication at client layer (this backward alarm indication will be
generated internally to the client layer by the client sink MEP).The
same OAM mechanism must be implemented in the other direction to
achieved bidirectional default notification.
3.2.2.3. Connectivity Fault Localisation
Preliminary note:
Regarding Fault Localisation, the tools required by a service provider
are not as sophisticated as the ones that are required by a network
provider. For example in the service architecture presented in figure 2,
the E2E service provider must be able to determine if the fault
affecting the E2E service comes from one of the access networks or from
the transit network. The precise localisation of the fault inside the
network is the responsibility of the relevant network provider. As a
consequence the Fault localisation described here is not required from a
SP perspective.
In case of loss of connectivity or fault notification it must be
possible to apply OAM mechanisms to further diagnostic the default:
identification of the type of fault (for example a link or equipment
failure) and localisation.
For connection oriented network this can be achieved directly using some
form of loopback mechanism (assuming the data path is already known).
Loopback request must be initiated only by the source MEP for each
transmission direction. Loopback must be possible at sink MEP (end to
end loopback for the ME) and at intermediate MIPs. For MIPs two loopback
options are possible:
. a selective loopback performed only by a destination MIP identified
in the loopback request (by its address or a MIP identifier),
. a multiple loopback performed by all MIPs located along the data
path.
In that case each answer to the loopback request must include a MIP
identifier to allow discrimination of answers by the source MEP which
originates the loopback request.
Delord, et. al. Expires April 2006 [Page 13]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
Non intrusive loopback is typically used in this case if only
connectivity is to be checked.
For connectionless network a preliminary step is necessary for the
identification of the data path followed by the service within the
network (some form of Trace Route function). This function can be
implemented using a multiple loopback mechanism, however it will hardly
provide visibility on network topology (in addition loopback request
message will be processed using the control plane inside each equipment
instead of the data plane).
Additional tools for discovery of network topology are then required for
connectionless network, as well as for discovery of service topology
(particularly in the case of Ethernet multipoint to multipoint
services).
Note: The interest of a fault localization function has to be carefully
studied for networks using mechanisms for automatic recovery, for
example Ethernet based networks using STP protocol (combined with the
fact that MAC tables are regularly aged erasing the data path history).
3.2.2.4. Performance Management (PM)
Performance management should be possible using OAM information. The
main objective of PM is to measure the level of performance of a network
or a service in order to verify the correct operation of the network or
the compliancy of the service with its negotiated SLA/SLS.
Performance Management (PM) mechanism could also be used to provide the
capability to avoid congestion on a network or used as a trigger to
switching traffic to another PSN tunnel which meets SLA/SLS for example.
The basic performance parameters that should be monitored are:
. effective bandwidth allocated to the service,
. number of lost end to end service data units,
. end to end transfer delay for service data units,
. Variation of this transfer delay (jitter).
Additional parameters can be monitored like enhanced statistics (number
of service data units transmitted, received, dropped at maintenance
points), service availability, etc.
Performance management requires the definition of dedicated OAM
information: testing signal to evaluate the error rate, time stamp to
evaluate transfer delay, etc. Simplified performance management is
possible using:
. connectivity verification mechanism (one way transfer delay,
estimated error rate)
Delord, et. al. Expires April 2006 [Page 14]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
. loopback mechanism (two way or round trip transfer delay estimation).
It should be noted that estimation of one way transfer delay assumes
the existence of a common clock reference.
Although desirable this requirement is less sensitive from an OAM point
of view as performance monitoring can be implemented using alternative
mechanisms more or less related to Network or Service Management System,
for example generating specific test data flows between service end
points with some form of statistical analysis or based on collection of
general network statistics. This is particularly true for a L2 VPN
service used to build an L3 VPN service.
Note: This point needs further developments to define precisely the
operational state conditions during which PM is applicable, as it is
done for MPLS LSP in ITU-T recommendation Y.1711.
4. PWE3 Applications & OAM Scenarios
This section describes different options offered to a SP for the E2E
service monitoring and their application to the different types of P2P
services.
The solutions are described here in the E2E SP perspective in the sense
that it should always be possible to provide E2E service supervision,
whatever the underlying networks implement (or not) in term of
supervision solution.
4.1. Service Supervision
The first requirement for the E2E SP is the capacity to monitor the end
to end services offered to his customers between service UNIs (between
CEs), with two main objectives :
. verify connectivity end to end,
. verify performances level to guarantee SLA (transfer delay, packet
loss, etc)
When an end to end service is declared in a not operational state the
E2E SP must be able to identify which element of the end to end service
architecture is affected by a fault. He must be able to unambiguously
determine if the correction procedure is under his responsibility or if
he must refer to one of the underlying network/service operators.
In the case of detection of a fault at E2E service level, the E2E SP
must have the possibility to verify separately the status of each AC and
the status of the PW. It must also be able to monitor the CE and PE
equipments to verify if they work correctly.
Delord, et. al. Expires April 2006 [Page 15]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
The verification of AC and PW segments imply some form of connectivity
verification mechanism. The monitoring of CEs and PEs can be done using
the E2E SP Network Management System.
The end customer may also want to monitor his service between his
equipments connected to CE, using some specific OAM flows that have to
be transported transparently using the E2E SP service.
Considering that the Access and Transit services have also to be
monitored by their respective network/service providers this leads to an
end to end architecture composed of typically four hierarchical OAM
domains.
The following paragraphs detail several scenarios to satisfy E2E service
supervision requirements. These scenarios differ on two aspects:
. E2E service supervision,
. Segment Supervision
4.1.1. E2E Service Supervision
This end to end service supervision can be based on a specific OAM
mechanism implemented between CEs, or on OAM information generated by
the different elements used to build the end to end service, collected
and/or reported to both CEs or directly to the E2E service level.
Three scenarios are detailed below. Selection between them depends on
various factors like the relative complexity between CE and PE, the type
of OAM functions required, the end to end architecture (PE service aware
or not, type of Access network, the possibility by legacy equipment to
support or not specific OAM functions, the PW encapsulation type, etc).
4.1.1.1. Using Specific End to End OAM Mechanism (option 1)
In this scenario a ME is defined from CE to CE associated with specific
OAM flows for end to end supervision. This ME is typically defined at
E2E SP service level. Each CE is then defined as MEP originating and
terminating OAM flows, both PEs can be defined as MIPs if they are
service aware, but this is not required.
This solution allows end to end supervision of service. Some form of
fault localisation is also possible if MIPs are defined at PE level
using for example a loopback mechanism.
The main advantage of this solution resides in the fact that the OAM
solution can be defined independently of other underlying elements of
the end to end architecture: availability or heterogeneity of OAM
information at AC and PW levels. In addition in its minimal form
(without MIP at PE level) only the CEs are involved in service
Delord, et. al. Expires April 2006 [Page 16]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
supervision, reducing complexity at PE level as well as potential
scalability issues.
This solution offers the possibility to build dedicated OAM mechanisms
(for example a Connectivity Verification procedure or the definition of
a Performance Management strategy) with characteristics directly linked
to specific parameters defined in service SLA.
The main drawback of this solution is the increase of functionalities
needed in the CE that can result from the support of specific OAM
mechanisms. This scenario is not applicable to a very simple CE
implementing only network termination functions (media converter type).
This solution also suffers from the lack of fault localisation
capability. If this function is necessary and cannot be implemented
using a loopback procedure as described above, additional mechanisms are
required for segments supervision.
4.1.1.2. Using Interworking between OAM Segments (option 2)
In this scenario a ME is defined for each segment associated with
specific OAM flows for segment supervision:
. ME is defined for each access part with MEPs at CE and PE
. Another ME is defined for transit part with MEPs at both PEs
End to end supervision is based on propagation of OAM information
between Maintenance Entities (between MEPs).
The segment Maintenance Entities can be defined at E2E SP service level
if both PEs are service aware, otherwise they should typically be
defined at AC and PW levels. Segment supervision is detailed in the
following paragraph.
If all MEs are defined at service level propagation of OAM information
is rather easy as the same technology is used end to end. If MEs are
defined at AC and PW levels the OAM flows used by each ME can be based
on different technologies and an Interworking function is generally
required to map OAM information between MEs.
OAM information reported at each CE allows simultaneously supervision of
end to end connectivity and fault localisation (if information on
localisation of fault could be propagated between MEs) in one direction.
At the CE level it is still necessary to generate aggregated information
applicable to end to end service.
This model is rather in contradiction with the basic OAM principle
described above stating that a MEP originates and terminates OAM flows.
This model can lead to a rather ambiguous situation where a ME may have
to carry alarm notifications that apply to other MEs (possibly not
Delord, et. al. Expires April 2006 [Page 17]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
adjacent MEs). This also implies in most cases an extension of existing
alarm notification messages to be able to discriminate alarm
notification applicable to the local ME from those affecting other MEs.
For example an AIS/FDI message carried over an AC must be able to
indicate if the reported fault affects the local AC, the PW or the
remote AC.
Though this interworking model seems hardly applicable for OAM domains
managed by separate operators, for example in the case of Access and
Transit networks, it may however be envisaged here if all MEs are part
of one or several OAM domain(s) managed by the same E2E SP.
The main advantage of this solution resides in the fact that both end to
end and segments supervision is implemented using only one layer of MEs.
As a consequence no specific OAM mechanisms are necessary at the CE
level for end to end supervision.
This solution has no real drawbacks if segment MEs are defined at
service level, except the fact that it is not fully in line with the
principle of OAM modelling. In that case interworking is reduced to
simple adaptation of OAM information using the same service technology
(for example in the case of a L2 VPN service if CE and PE implement
Ethernet bridge functions).
In the case where MEs are defined at AC and PW levels, this solution is
first conditioned by the fact that OAM mechanisms must be available at
AC and PW levels. This point is mitigated by the fact that both AC and
PW are implemented by the E2E SP who could add the necessary missing
blocks (ideally based on the same OAM mechanisms to ease interworking).
It has however one main drawback: the PE will need to implement mapping
function resulting from the introduction of the Interworking function.
This is particularly true when AC and PW are based on different
technologies, particularly if it is necessary to map OAM information
between connection oriented and connectionless oriented technologies.
This case is obviously realistic as it corresponds to an Ethernet AC
mapped to a MPLS PW.
4.1.1.3. Using Client / Server relation (option 3)
In this scenario a ME is defined for each segment associated with
specific OAM flows for segment supervision:
. ME is defined for each access part with MEPs at CE and PE,
. Another ME is defined for transit part with MEPs at both PEs.
An additional ME is defined between CEs (each CE is a MEP) for end to
end supervision. In this scenario PEs must be service aware so both PEs
can be defined as MIPs, but this is not required. Client/server model is
Delord, et. al. Expires April 2006 [Page 18]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
used for propagation of OAM information between segment MEs (server) and
end to end ME (client).
Like in the previous scenario the segment MEs can be defined at E2E SP
service level (as both PEs are service aware), they could also be
defined at AC and PW levels. Segment supervision is detailed in the
following paragraph.
If all MEs are defined at service level, propagation of OAM information
between server and client layer is rather easy as the same technology is
used. If segment MEs are defined at AC and PW levels, the OAM flows used
by each ME can be based on different technologies, and an adaptation
function is generally required to build OAM messages appropriate to the
client layer.
OAM information reported by the server layers to the client layer is
composed of forward fault notification (AIS/FDI). It simultaneously
allows monitoring of E2E service connectivity and fault localisation
between segments. Compared to the first scenario, the end to end ME does
not require the implementation of a connectivity verification mechanism.
It only requires implementation of fault notification processing.
Compared to option 2 this model is fully in line with the principle that
MEPs originate and terminate OAM flows and can propagate OAM information
to the client layer.
With this solution, end to end supervision is mainly built using
segments supervision which results in very limited OAM mechanisms needed
at CE level (specific functions are however required for AC
supervision)requiring the implementing of propagation functions.
This model has no real drawback, except that it can only be used if PEs
are service aware in order to be able to generate alarm notification at
E2E service level.
4.1.2. Segment Supervision
The supervision of a segment can be implemented using mainly three
different options, already partially described in the previous
paragraph. In all scenarios a ME is defined for each segment, associated
with specific OAM flows for segment supervision:
. ME is defined for each Access part with MEPs at CE and PE
. ME is defined for Transit part with MEPs at both PEs
The differences between the various options are detailed below.
If performance monitoring is important at E2E service level, segment
monitoring is mainly focused on connectivity verification only (with
fault localisation treated at the underlying network level).
Delord, et. al. Expires April 2006 [Page 19]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
4.1.2.1. MEs at Service Level
In this scenario MEs are defined at service level and mapped over the
segments, independently of underlying ACs and PW. This scenario is only
applicable if both PEs are service aware in order to be able to generate
and terminate OAM flows at service level.
The main advantage of this scenario resides in the fact that segment
supervision is independent of the underlying ACs and PW, and that the
same OAM mechanisms can be used for all segments, directly linked to E2E
service (supervision parameters can be fine tuned depending on service
SLA). It also facilitates end to end supervision based on interworking
or on client/server model.
In addition to the restriction to service aware PEs this scenario
requires specific functions at CE and PE levels, and may duplicate
existing mechanisms already available at AC and PW levels (for example
VCCV for PW).
Note: This is typically what is currently done in IP-VPN to monitor the
access part between the CE and the PE, an ICMP Ping message is generated
from the PE to the CE to check their connectivity.
4.1.2.2. Specific OAM solution for supervision of each segment
In this scenario MEs are defined at ACs and PW levels (independently of
transported E2E service, even if alarm propagation to service level is
possible). As ACs and PW generally use different technologies, different
OAM mechanisms have to be used for ACs and PW supervision.
The main advantage of this scenario resides in the fact that it is
applicable in all cases even if PEs are not service aware. It can reuse
existing mechanisms available for ACs and PW supervision (for example
VCCV for PW). This solution is also independent of underlying Access and
Transit services and can use specific supervision parameters (common to
both AC and PW) depending on transported services and related SLA (like
the previous one).
It however has less relation with E2E service resulting in a more
complex implementation of the client /server model for end to end
supervision. It also requires specific OAM mechanisms at CE and PE
levels.
4.1.2.3. Client/Server model with underlying network services
In this scenario the supervision mechanisms available at the underlying
Access and Transit services (server layers) are used with propagation of
OAM information to the client ACs or PW (client layers). This scenario
Delord, et. al. Expires April 2006 [Page 20]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
is of course conditioned by the existence of such mechanisms at Access
and Transit levels.
The main advantage of this scenario resides in the fact that no specific
OAM mechanisms are required for segments supervision, resulting in a
simplification of CEs and PEs. On the other hand, as an Access or a
Transit service generally transports several services (particularly a
Transit service), monitoring of the segment may not be finely tuned to
meet the E2E service supervision requirements.
4.2. Application to network scenarios
This part of the document focuses on examples of Point to Point services
(either homogeneous or heterogeneous) describing how the MEs are defined
and where the MEPs and MIPs are located depending on the chosen
monitoring option.
4.2.1. Homogenous Services
A service is considered to be homogenous when the two Customer
interfaces at CE1 and CE2 are of the same type. In this case, there are
two alternatives that are explained in the following paragraphs.
The first one is to have a PE that is Service Aware (SA). This means
that the PW encapsulation type is of the same type as the E2E service
(ACs are terminated/originated at the ingress/egress of each PE and the
PW encapsulates native service PDUs).
In the second case where the PW Encapsulation type is different from the
E2E service, the PE is Non Service Aware (NSA) which implies that the PE
does not have any knowledge of the E2E emulated service.
This configuration could be considered for P2P services where no native
service PDUs processing is required at PE level.
For example, considering an Ethernet over ATM encapsulation (RFC2684 B)
is performed at CE1 to transport an E2E Ethernet service over an ATM
access network. If the PW is of Ethernet type, then PE1 needs to de-
encapsulates Ethernet from ATM and encapsulates directly Ethernet over
the PW. If the PW is of ATM type then the PE only processes ATM cells,
and has no idea that in fact the E2E service is Ethernet based.
4.2.1.1. PE Service Aware (PE SA)
Figure 3 shows for the case of service aware PEs, how the MEs are
defined and where the MEPs and MIPs are located for the different layers
of the model considering the three options presented in this document.
Delord, et. al. Expires April 2006 [Page 21]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
+----+ +----+
+-----+ | PE1|===============| PE2| +-----+
| |------|............PW1..........|--------| |
| CE1 | | | | | | CE2 |
| |------|............PW2..........|--------| |
+-----+ | |===============| | +-----+
+----+ +----+
opt1| A MEP---MIP-----------------------------------------MIP-----MEP
| ^ ^
| | |
| B1 MEP--------MIP------------------MIP---------MEP
opt2| A MEP---MIP-----------------------------------------MIP-----MEP
| ^ ^
| | |
|B1 or B2 MEP-----MEP<->MEP-------------MEP<->MEP-----MEP
opt3| A MEP---MIP-----------------------------------------MIP-----MEP
| ^ ^
| | |
| B1 MEP-------MIP---------------------MIP-------MEP
| ^ ^ ^ ^ ^ ^
| | | | | | |
| B2 MEP----MEP MEP-----------------MEP MEP------MEP
A is the E2E Customer Layer
B1 is the E2E Service Provider layer
B2 is the AC/PW/AC Layer
FIGURE 3: MEs definition and MEPs and MIPs location for PE SA
As PE is service aware it is possible to define a MEP/MIP at E2E service
level for both PEs, for the three options.
The MIP at CE level for E2E customer service is optional as this layer
could be completely transparent for the CE (for example a L3 service
implemented between CPEs over a E2E L2 service provided by the SP
between the CE interfaces).
. Option 1 is based on end to end supervision between CEs
. Option 2 is based on segments supervision plus interworking. OAM
handling for this scenario is described in OAM-Message Mapping & VPWS
interworking
. Option 3 is based on client/server model. In this scenario the errors
can happen at any of the following location: AC, PW, AS, PSN Tunnel
or PE itself
Delord, et. al. Expires April 2006 [Page 22]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
For all scenarios, the propagation of an alarm will reach the first MEP
that will terminate this error by entering the relevant error state, by
sending a backward alarm indication towards its peer MEP. Depending on
the option chosen the MEPs will also generate an alarm on the upper
layer if they are MIPs or MEPs of this higher layer (option 3),
otherwise they will have to pass the information along (option 2).
For example if we take option 2 and 3, for an error happening on an AC,
in option 2, the PE will receive an alarm at the AC level, as it is not
a MIP of the higher layer (which is the E2E SP layer) it will have to
pass it over to the next MEP of the same level (for example map it onto
a VCCV alarm or an LDP Status message). Considering option 3, if the
same error occurs in the AC, the alarm will be terminated for that level
at the PE and propagated at the upper layer (E2E SP layer).
4.2.1.2. PE Non Service Aware (PE NSA)
As explained above, PE NSA can happen when the PW type is different from
the E2E service.
However, in such a situation, it is possible to see the CE as two
logical devices in one. One part of the CE does the mapping between the
E2E service and the technology that will be carried over the PW (for
example the RFC 2684B). The second part acts as if the E2E service was
the one carried onto the PW (referred in figure 4 as B1 bis level).
Therefore, even if the PE is NSA at B1 level it could be considered as
service aware at B1 bis level. One can then fall back into the previous
category, which means that both IW and client/server models are still
applicable.
Figure 4 shows in the case of non service aware PEs how the MEs are
defined and where the MEPs and MIPs are located for the different layers
of the model including the two logical devices in the CE and considering
the three options presented in this document.
Delord, et. al. Expires April 2006 [Page 23]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
+----+ +----+
+-----+ | PE1|===============| PE2| +-----+
| |------|............PW1..........|--------| |
| CE1 | | | | | | CE2 |
| |------|............PW2..........|--------| |
+-----+ | |===============| | +-----+
+----+ +----+
opt1| A MEP---MIP-----------------------------------------MIP-----MEP
| ^ ^
| | |
| B1 MEP--------MIP------------------MIP---------MEP
(or B1 bis)
opt2| A MEP---MIP-----------------------------------------MIP-----MEP
| ^ ^
| | |
| B2 MEP-----MEP<->MEP-------------MEP<->MEP-----MEP
(or B1 bis)
opt3| A MEP---MIP-----------------------------------------MIP-----MEP
| ^ ^
| | |
| B1(bis) MEP-------MIP---------------------MIP-------MEP
| ^ ^ ^ ^ ^ ^
| | | | | | |
| B2 MEP----MEP MEP-----------------MEP MEP------MEP
A is the E2E Customer Layer
B1 is the E2E Service Provider Layer for the Native Service
B1(bis) is the E2E Service Provider layer for the Non Native Service
B2 is the AC/PW/AC Layer
FIGURE 4: MEs definition and MEPs and MIPs location for PE NSA
As PE is not service aware it is not possible to define a MEP/MIP at E2E
service level for both PEs, for the three options. This is however
possible for B1 bis level.
The MIP at CE level for E2E customer service is optional as this layer
could be completely transparent for the CE (for example a L3 service
implemented between CPEs over a E2E L2 service provided by the SP
between the CE interfaces).
Delord, et. al. Expires April 2006 [Page 24]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
4.2.1.3. Conclusion for Homogenous Services
The choice for one option over the others is basically under the SP
responsibility. It is important to point out though that the use of the
client/server method (option 3) provides some advantages over the other
two (in terms of transparency for example). However, if for some reason
this solution is not applicable, then option 1 or option 2 should be
used depending on global architecture, possibility of legacy equipments,
etc...
4.2.2. Heterogeneous Services
A service is considered to be heterogeneous when the two customer
interfaces at CE1 and CE2 are of a different type (Ethernet on one side
and ATM on the other one for example).
Of course, some sort of service interworking must take place here. There
are two ways of doing it, depending on where the IW function is located.
In both configurations, option 1 based on end to end supervision at
service level does not seem relevant as the service is not homogenous
end to end.
If the IWF takes place in one of the PEs (either PE1 or PE2), this is
called a Single Sided IW, then a service interworking can be achieved.
For example if we want to connect two sites, one in Ethernet and the
other one in ATM, one of the PE can do some sort of technology
interworking directly between Ethernet and ATM (similar to FRF.8.1 for a
mapping between FR and ATM).
If SSI takes place, then it is possible to reuse option 3 for the E2E
monitoring. Option 2 based on interworking is also applicable at E2E
service level or at AC/PW/AC level.
If the IWF takes place in both PEs (PE1 & PE2), this is called Double
Sided IW (and is defined in the draft [ARP-MEDIATION]) that uses IP
Pseudowires, then no real service interworking can be done and
therefore, only network IW can occur (between both ACs and the PW).
If DSI takes place, then option 3 is not feasible any more since there
is no possibility to map an L2 alarm onto an IP alarm. Therefore, option
2 at AC/PW/AC level is the only one applicable in this scenario.
Figure 5 shows how the MEs can be defined for heterogenous scenarios and
where the MEPs and MIPs are located for the different layers of the
model considering the three options presented in this document.
Delord, et. al. Expires April 2006 [Page 25]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
+----+ +----+
+-----+ | PE1|===============| PE2| +-----+
| |------|............PW1..........|--------| |
| CE1 | | | | | | CE2 |
| |------|............PW2..........|--------| |
+-----+ | |===============| | +-----+
+----+ +----+
opt2 |A MEP---MIP--------*---------------------*----------MIP-----MEP
+DSI | ^ ^
| | |
|B2 MEP----MEP<*>MEP-------------MEP<*>MEP------MEP
opt2 |A MEP---MIP------------------------------*----------MIP-----MEP
+SSI | ^ ^
| | |
|B1 or B2 MEP---MEP<->MEP-------------MEP<*>MEP------MEP
opt3 |A MEP---MIP------------------------------*----------MIP-----MEP
+SSI | ^ ^
| | |
|B1 MEP-------MIP-------------------MIP*--------MEP
| ^ ^ ^ ^ ^ ^
| | | | | | |
|B2 MEP-----MEP MEP---------------MEP MEP-------MEP
A is the E2E Customer Layer
B1 is the E2E Service Provider layer
B2 is the AC/PW/AC Layer
* represents an interworking function (either L2 to L2 either L2 to IP
PW in the case of the DSI scenario)
FIGURE 5: MEs definition and MEPs and MIPs location for layered model
4.2.2.1. Conclusion for Heterogeneous Services
The choice for SSI or DSI is basically the responsibility of the SP
depending on the same parameters as usual. However it is important to
notice that only the SSI scenario allows for service interworking
whereas the DSI will always require network interworking.
5. Acknowledgments
Delord, et. al. Expires April 2006 [Page 26]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
TBD
6. Security Considerations
Security issues resulting from this draft will be discussed in greater
depth at a later point.
7. Normative References
[L2VPN-OAM-FRW] draft-ietf-l2vpn-oam-req-frmk-04.txt
8. Informative References
[L2VPN-OAM-FRW] draft-ietf-l2vpn-oam-req-frmk-04.txt
[WILLIS] draft-willis-pwe3-requirements-00.txt
[OAM-MSG] draft-ietf-pwe3-oam-msg-map-01.txt
[VCCV] draft-ietf-pwe3-vccv-04.txt
[PWE3-CNTL] draft-ietf-pwe3-control-protocol-06.txt
[LDP-PROV] draft-ietf-l2vpn-signaling-01.txt
[VPWS-IW-OAM] draft-aissaoui-l2vpn-vpws-iw-oam-00.txt
[MH-PW Req] "Requirements for inter domain Pseudo-Wires",draft-martini-
pwe3-mh-pw-requirements-01.txt (Work in Progress)
[L2VPN FWK] "Framework for Layer 2 Virtual Private Networks
(L2VPNs)",draft-ietf-l2vpn-l2-framework-05.txt (Work in Progress)
9. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
Delord, et. al. Expires April 2006 [Page 27]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
10. Authors' Addresses
Simon Delord
Uecomm
658 Church St
Richmond, VIC, 3121, Australia
Email: sdelord@uecomm.com.au
Philippe Niger
France Telecom
2 av. Pierre Marzin
22300 LANNION, France
Email: philippe.niger@francetelecom.com
Yuichi Ikejiri
NTT Communications
1-6 Uchisaiwai-cho 1-chome Chiyoda-ku, Tokyo
100-8019 Japan
Email: y.ikejiri@ntt.com
Yuichiro Wada
NTT Communications
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku,
Tokyo 163-1421, JAPAN
Email: yuichiro.wada@ntt.com
Deborah Brungard
ATT
200S. Laurel Ave.
Middletown, NJ 07748
Email:dbrungard@att.com
Lei Zhu
Sprint
6220 Sprint Parkway
Overland Park, Kansas 66251
Email: lei.zhu@mail.sprint.com
Alain Vedrenne
Equant
Heraklion, 1041 route des Dolines, BP347
06906 Sophia Antipolis Cedex, France
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Delord, et. al. Expires April 2006 [Page 28]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
Tokyo 102-8460, JAPAN
E-mail: ke-kumaki@kddi.com
Dinesh Mohan
Nortel
3500 Carling Ave
Ottawa, ON K2H8E9
Email: mohand@nortel.com
Vasile Radoaca
Consultant
Email : radoaca@hotmail.com
Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: sajassi@cisco.com
11. APPENDIXES
11.1. Detailed description of each layer of the model
11.1.1. Network Layer
In the general case this layer is composed of a set of homogenous and
independent networks, each operated by a separate network operator. The
different networks are completely independent with client/server
relations with the E2E SP layer, and do not require relations between
them. Each network implements its own mechanisms necessary for the
correct operation of the network and for the support of the offered
Access/Transit services (data forwarding, signalling, QoS, OAM, etc).
In the considered architecture there are:
. two Access Providers offering Access Services to deliver connectivity
through Access Networks for connection of CEs to PEs (one Access
Network for each POP in figure 2)
. one Transit Provider offering Transit Service to deliver connectivity
through the PSN for interconnection of PEs. The Transit Service is
equivalent to the PSN tunnel defined in the IETF reference model.
11.1.2. E2E SP Layer
This layer is composed of the two sub-layers e.g. A network sub-layer
that encompasses all the functionalities specifically implemented to
support the end to end service offered by the SP to his customers:
. AC between CE and PE,
. PW between PEs,
Delord, et. al. Expires April 2006 [Page 29]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
. Adaptation functions at CE level,
. Interworking functions at PE level.
These functionalities are implemented only in SP equipments (CEs and
PEs). If these functions can be conditioned by the underlying network
layers, they are transparent to these underlying network layers. They
also provide some form of homogenous server layer for the support on E2E
SP service, independently of the underlying network layers.
As indicated in the IETF reference model a PW is only processed at PE
level and is transported transparently through the PSN using a PSN
tunnel. In the same manner an AC is processed only at CE and PE level
and is transported transparently through the Access Network using an
Access Service.
From figure 2 it can be seen that the AS provides connectivity through
the Access network as the PSN tunnel does through the Core network. An
AC is implemented between the CE and the PE and uses the connectivity
provided by an Access Service in a similar manner as a PW does between
two PEs using a PSN Tunnel. In others words an AC provides some form of
service emulation through the Access network.
Based on this analogy between AC and PW a clarification of the AC
functionalities can be proposed:
. an AC provides an encapsulation mechanism for the transport of E2E SP
service data units over the Access Service,
. an AC provides a multiplexing mechanism to allow several E2E SP
services to share the same Access Service, in addition an AC can
provide additional functions for AC management: signalling for
establishment/tear down, OAM for supervision of emulated service,
etc.
This definition could be adapted to a specific configuration. For
example, if the E2E SP service and the Access service are compatible
(use the same technology) the encapsulation function may not be
necessary or if the Access service is used to transport only a single
E2E SP service the multiplexing function is not required.
Adaptation functions at CE level may be required to allow transport of
E2E SP service data units over the Access Network (for example using
encapsulation mechanism). Interworking functions at PE level may be
required to map information between AC and PW (for example OAM
information). These interworking functions can imply interworking
between different technologies used for AC and PW (e.g mapping an ATM
AIS into a VCCV alarm using BFD).
. The end to end SP service: this is the end to end service offered by
the SP to his customers, providing connectivity from CE to CE. This
service is implemented using the generic functionalities offered by
the network sub-layer (connectivity, QoS, OAM, etc), eventually
Delord, et. al. Expires April 2006 [Page 30]
Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005
complemented with additional functions specific to the service. These
functions are based on processing of E2E SP service data units, for
example frame replication for VPLS service.
11.1.3. Customer Layer
This layer is composed of the customer end to end service. In general
this service should be transported transparently using the connectivity
delivered by the end to end SP service (data PDU, signalling and OAM
messages, etc).
12. IPR Notice
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.
