draft-ietf-l2vpn-oam-req-frmk-01.txt   draft-ietf-l2vpn-oam-req-frmk-02.txt 
Internet Draft Document Dinesh Mohan (Editor) Internet Draft Document Dinesh Mohan (Editor)
Internet Draft Nortel Networks Internet Draft Nortel
Expires: April 2005 Ali Sajassi (Editor) Expires: August 2005 Ali Sajassi (Editor)
Cisco Systems Cisco Systems
October 2004 February 2005
VPLS OAM Requirements and Framework L2VPN OAM Requirements and Framework
draft-ietf-l2vpn-oam-req-frmk-01.txt draft-ietf-l2vpn-oam-req-frmk-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we represent that any applicable By submitting this Internet-Draft, we represent that any applicable
patent or other IPR claims of which we are aware have been disclosed, patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and any of which we are aware have been or will or will be disclosed, and any of which we are aware have been or will
be disclosed, and any of which we become aware will be disclosed in be disclosed, and any of which we become aware will be disclosed in
accordance with RFC 3668. accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Conventions Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 document are to be interpreted as described in RFC 2119
RELATED DOCUMENTS RELATED DOCUMENTS
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework- http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-
03.txt 05.txt
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements- http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-
03.txt 03.txt
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo................................................1
Abstract...........................................................1 Abstract...........................................................1
Conventions........................................................1 Conventions........................................................1
1. Introduction....................................................2 1. Introduction....................................................3
2. L2VPN Services & Networks.......................................4 2. L2VPN Services & Networks.......................................4
3. OAM Layering....................................................5 3. L2VPN OAM Framework.............................................5
3.1. OAM Domains...................................................6 3.1. OAM Layering..................................................5
3.2. MEPs & MIPs...................................................7 3.2. OAM Domains...................................................6
3.3. MEP and MIP Identifiers.......................................8 3.3. MEPs and MIPs.................................................6
4. VPLS OAM Requirements...........................................9 3.4. MEP and MIP Identifiers.......................................7
4.1. Discovery.....................................................9 3.5. OAM Framework for VPLS........................................7
4.2. Connectivity Fault Management.................................9 3.5.1. VPLS as Bridged LAN Service.................................7
4.2.1. Connectivity Fault Detection................................9 3.5.2. VPLS as a Network...........................................8
4.2.2. Connectivity Fault Verification.............................9 3.5.3. VPLS as LAN/VLAN Emulation..................................8
4.2.3. Connectivity Fault Localization............................10 3.5.4. VPLS OAM Layering...........................................9
4.2.4. Connectivity Fault Alarm...................................10 3.5.5. VPLS OAM Domains............................................9
4.3. Frame Loss...................................................10 3.5.6. VPLS MEPs & MIPs...........................................10
4.4. Frame Delay..................................................10 3.5.7. VPLS MEP and MIP Identifiers...............................11
4.5. Frame Delay Variation........................................11 3.6. OAM Framework for VPWS.......................................11
4.6. Data Path Execution..........................................11 3.7. OAM Framework for IPLS.......................................11
4.7. Scalability..................................................11 4. L2VPN OAM Requirements.........................................11
4.8. Extensibility................................................12 4.1. VPLS OAM Requirements........................................11
4.9. Security.....................................................12 4.1.1. Discovery..................................................11
4.10. Transport Independence......................................12 4.1.2. Connectivity Fault Management..............................11
4.11. Application Independence....................................13 4.1.3. Connectivity Fault Detection...............................12
4.12. Backward Compatibility......................................13 4.1.4. Connectivity Fault Verification............................12
4.13. Availability................................................13 4.1.5. Connectivity Fault Localization............................12
5. Acknowledgments................................................13 4.1.6. Connectivity Fault Alarm...................................12
6. Security Considerations........................................14 4.1.7. Frame Loss.................................................12
7. Intellectual Property Considerations...........................14 4.1.8. Frame Delay................................................13
8. Full Copyright Statement.......................................14 4.1.9. Frame Delay Variation......................................13
9. IPR Notice.....................................................14 4.1.10. Data Path Execution.......................................13
10. Normative References..........................................15 4.1.11. Scalability...............................................14
11. Informative References........................................15 4.1.12. Extensibility.............................................14
12. Authors' Addresses............................................16 4.1.13. Security..................................................14
4.1.14. Transport Independence....................................15
4.1.15. Application Independence..................................15
4.1.16. Backward Compatibility....................................15
4.1.17. Availability..............................................15
4.2. VPWS OAM Requirements........................................16
4.3. IPLS OAM Requirements........................................16
5. Acknowledgments................................................16
6. Security Considerations........................................16
7. Intellectual Property Considerations...........................16
8. Full Copyright Statement.......................................16
9. IPR Notice.....................................................17
10. Normative References..........................................17
11. Informative References........................................17
12. Authors' Addresses............................................18
1. Introduction 1. Introduction
This draft provides framework and requirements for Virtual Private This draft provides framework and requirements for Virtual Private
LAN Service (VPLS) Operation, Administration and Maintenance (OAM). LAN Service (VPLS) Operation, Administration and Maintenance (OAM).
The scope of OAM for any service and/or transport/network The scope of OAM for any service and/or transport/network
infrastructure technologies can be very broad in nature. OSI has infrastructure technologies can be very broad in nature. OSI has
defined the following five generic functional areas for network defined the following five generic functional areas for network
management, commonly abbreviated as "FCAPS" [NM-Standards]: a) Fault management, commonly abbreviated as "FCAPS" [NM-Standards]: a) Fault
Management, b) Performance Management, c) Configuration Management, Management, b) Performance Management, c) Configuration Management,
d) Accounting Management, and e) Security Management. d) Accounting Management, and e) Security Management.
This draft focuses on the Fault and Performance Management aspects. This draft focuses on the Fault and Performance Management aspects.
Other functional aspects of FCAPS are for further study. Other functional aspects of FCAPS are for further study.
[L2VPN-FRWK] specified three different types of Layer 2 VPN (i.e. [L2VPN-FRWK] specified three different types of Layer 2 VPN (i.e.
services). These are VPWS, VPLS and IPLS. The framework and services). These are VPWS, VPLS and IPLS.
requirements presented in this draft applies to VPLS.
Fault Management can typically be viewed in terms of the following Fault Management can typically be viewed in terms of the following
categories: categories:
- Fault Detection - Fault Detection
- Fault Verification - Fault Verification
- Fault Isolation - Fault Isolation
- Fault Notification - Fault Notification
- Fault Recovery - Fault Recovery
skipping to change at page 3, line 40 skipping to change at page 4, line 4
Fault Detection deals with mechanism(s) that can detect both hard Fault Detection deals with mechanism(s) that can detect both hard
failures, such as link and device failures, and soft failures, such failures, such as link and device failures, and soft failures, such
as software failure, memory corruption, mis-configuration, etc. as software failure, memory corruption, mis-configuration, etc.
Typically a lightweight protocol is desirable to detect the fault Typically a lightweight protocol is desirable to detect the fault
and thus it would be prudent to verify the fault via Fault and thus it would be prudent to verify the fault via Fault
Verification mechanism before taking additional steps in isolating Verification mechanism before taking additional steps in isolating
the fault. After verifying that a fault has occurred along the data the fault. After verifying that a fault has occurred along the data
path, it is important to be able to isolate the fault to a given path, it is important to be able to isolate the fault to a given
device or link. Therefore, a Fault Isolation mechanism is needed in device or link. Therefore, a Fault Isolation mechanism is needed in
Fault Management. Fault Notification mechanism can be used in Fault Management. Fault Notification mechanism can be used in
conjunction with Fault Detection mechanism to notify the upstream conjunction with Fault Detection mechanism to notify the upstream
and downstream devices of a fault. For example, when there is a and downstream devices of a fault. For example, when there is a
client/server relationship between two layered networks, Fault client/server relationship between two layered networks; Fault
Detection at the server layer will require the following Fault Detection at the server layer will require the following Fault
Notification: Notification:
- sending a forward Fault Notification into the client layer - sending a forward Fault Notification into the client layer
network(s) using the Fault Notification format appropriate to network(s) using the Fault Notification format appropriate to
the client layer the client layer
- sending a backward Fault Notification, if applicable, in the - sending a backward Fault Notification, if applicable, in the
reverse direction in the server layer network reverse direction in the server layer network
Finally, Fault Recovery deals with recovering from the detected Finally, Fault Recovery deals with recovering from the detected
failure by switching to an alternate available device or link (e.g., failure by switching to an alternate available device or link (e.g.,
skipping to change at page 4, line 21 skipping to change at page 4, line 37
Frame Loss, Frame Delay, Frame Delay Variation (aka Jitter) etc Frame Loss, Frame Delay, Frame Delay Variation (aka Jitter) etc
across managed entities when the managed entity are in available across managed entities when the managed entity are in available
state. Performance Management is suspended across unavailable state. Performance Management is suspended across unavailable
managed entities. This draft introduces some of these performance managed entities. This draft introduces some of these performance
parameters. parameters.
This document provides a description and a reference model for OAM This document provides a description and a reference model for OAM
layering and furthermore emphasizes the importance of proper layering and furthermore emphasizes the importance of proper
independent layering in design and development of OAM functionality. independent layering in design and development of OAM functionality.
This proposal is aligned with the current discussions in other
standard bodies and groups such as ITU-T Q.3/13, IEEE 802.1, and MEF
which are addressing Ethernet network and service OAM.
2. L2VPN Services & Networks 2. L2VPN Services & Networks
As described in [L2VPN-REQ], following Figure 1 shows a L2VPN As described in [L2VPN-REQ], following Figure 1 shows a L2VPN
reference model. L2VPN A represents a point-to-point service while reference model. L2VPN A represents a point-to-point service while
L2VPN B represents a bridged service. L2VPN B represents a bridged service.
+-----+ +-----+ +-----+ +-----+
+ CE1 +--+ +--| CE2 | + CE1 +--+ +--| CE2 |
+-----+ | ..................... | +-----+ +-----+ | ..................... | +-----+
L2VPN A | +----+ +----+ | L2VPN A L2VPN A | +----+ +----+ | L2VPN A
skipping to change at page 5, line 4 skipping to change at page 5, line 28
| | switching | | switching
+-----+ | instance +-----+ | instance
| CE3 | | CE3 |
+-----+ +-----+
L2VPN B L2VPN B
Figure 1: L2VPN Reference Model Figure 1: L2VPN Reference Model
[L2VPN-FRWK] specifies VPWS, VPLS and IPLS services. VPWS is a [L2VPN-FRWK] specifies VPWS, VPLS and IPLS services. VPWS is a
point-to-point service where CEs are presented with point-to-point point-to-point service where CEs are presented with point-to-point
virtual circuits. VPLS is a bridged LAN service provided to a set of virtual circuits. VPLS is a bridged LAN service provided to a set of
CEs that are members of a VPN. CEs that are member of the same CEs that are members of a VPN. CEs that are member of the same
service instance communicate with each other as if they are service instance communicate with each other as if they are
connected via a bridged LAN. IPLS is a special VPLS which is used to connected via a bridged LAN. IPLS is a special VPLS which is used to
carry only IP service packets. carry only IP service packets.
[L2VPN-REQ] assumes the availability of runtime monitoring protocols
while defining requirements for management interfaces. This draft
specifies the requirements and framework for operations,
administration and maintenance (OAM) protocols between network
devices.
3. L2VPN OAM Framework
3.1. OAM Layering
The point-to-point or bridged LAN functionality is emulated by a The point-to-point or bridged LAN functionality is emulated by a
network of PEs to which the CEs are connected. This network of PEs network of PEs to which the CEs are connected. This network of PEs
can belong to a single network operator or can span across multiple can belong to a single network operator or can span across multiple
network operators. Furthermore, it can belong to a single service network operators. Furthermore, it can belong to a single service
provider or can span across multiple service providers. A service provider or can span across multiple service providers. A service
provider is responsible for providing L2VPN services to its provider is responsible for providing L2VPN services to its
customers; whereas, a network operator (aka facility provider) customers; whereas, a network operator (aka facility provider)
provides the necessary facilities to the service provider(s) in provides the necessary facilities to the service provider(s) in
support of their services. A network operator and a service support of their services. A network operator and a service
provider can be the same entity or they can be different provider can be the same entity or they can be different
administrative organizations. administrative organizations.
[L2VPN-REQ] assumes the availability of runtime monitoring protocols Different layers involved in realizing L2VPNs include service layer
while defining requirements for management interfaces. This draft and network layers. Network layers can be iterative. In context of
specifies the requirements and framework for operations, L2VPNs, the service layers consists of VPLS, VPWS (e.g. Ethernet,
administration and maintenance (OAM) protocols between network ATM, FR, HDLC, SONET, etc. point-to-point emulation), and IPLS.
devices. Similarly in context of L2VPNs, network layers consist of MPLS/IP
networks. The MPLS/IP networks can consist of networks links
realized by different technologies e.g. SONET, Ethernet, ATM etc.
Each layer is responsible for its own OAM. This document provides
the OAM framework and requirements for L2VPN services and networks.
3.2. OAM Domains
When discussing OAM tools for L2VPNs it is important to provide OAM
capabilities and functionality over each domain that a service
provider or a network operator is responsible for. For these
reasons, it is also important that OAM frames are not allowed to
enter/exit other domains. We define an OAM domain as a network
region over which OAM frames operate unobstructed as explained
below.
At the edge of an OAM domain, filtering constructs should prevent
OAM frames from exiting and entering that domain. OAM domains can be
nested but not overlapped. In other words, if there is a hierarchy
of the OAM domains, the OAM messages of a higher-level domain pass
transparently through the lower-level domains but the OAM messages
of a lower-level domain get blocked/filtered at the edge of that
domain.
In order to facilitate the processing of OAM messages, each OAM
domain can be associated with a level at which it operates. Higher
level OAM domains can contain lower level OAM domains but the
converse is not true.
A PE can be part of several OAM domains with each interface
belonging to the same or a different OAM domain. A PE shall block
outgoing OAM messages and filter out incoming OAM messages whose
domain level is lower or same to the one configured on that
interface and pass through the OAM messages whose domain level is
higher than the one configured on that interface.
Generically, L2VPNs can be viewed as consisting of customer OAM
domain, service provider OAM domain, and network operator OAM domain
as depicted later in Figure 3.
3.3. MEPs and MIPs
Maintenance End Points (MEPs) are responsible for origination and
termination of OAM messages. MEPs are located at the edge of their
corresponding OAM domains. Maintenance Intermediate Points (MIPs)
are located within their corresponding OAM domains and they normally
pass OAM messages but never initiate them. Since MEPs are located at
the edge of their OAM domains, they are responsible for filtering
outbound OAM frames from leaving the OAM domain or inbound OAM
frames from entering the OAM domain. MEPs and MIPs correspond to a
PE or more specifically to an interface of a PE. For example, an OAM
message can be said to originate from an ingress PE or more
specifically an ingress interface of that PE.
Since OAM domains are hierarchical as described above, the MEPs and
MIPs associated with the OAM domains become hierarchical as well. A
MEP of a higher-level OAM domain is always a MEP of a lower-level
OAM domain but the converse is not always true since the MEP of
lower-level OAM domain can either be MIP or a MEP of a higher-level
OAM domain. Furthermore, the MIPs of a lower-level OAM domain are
always transparent to the higher-level OAM domain (e.g., OAM
messages of a higher-level OAM domain are not seen by MIPs of a
lower-level OAM domain and get passed through them transparently).
3.4. MEP and MIP Identifiers
As mentioned previously, OAM at each layer should be independent of
other layers e.g. service layer OAM should be independent of
underlying transport layer. MEPs and MIPs at each layer should be
identified with layer specific identifiers.
3.5. OAM Framework for VPLS
Virtual Private LAN Service (VPLS) is used in different contexts. In
general, VPLS is used in the following contexts: a) as a bridged LAN
service over networks, some of which are MPLS/IP, b) as an MPLS/IP
network supporting these bridged LAN services, and c) as LAN/VLAN
emulation.
3.5.1. VPLS as Bridged LAN Service
The most common definition for VPLS is for bridged LAN service over
an MPLS/IP network. The service coverage is considered end-to-end
from UNI to UNI (or AC to AC) among the CE devices and it provides a
virtual LAN service to the attach CEs belonging to that service
instance. The reason it is called bridged LAN service is because the
VPLS-capable PE provide this end-to-end virtual LAN service
performing bridging functions (either full or a subset) as described
in the [L2VPN-FRWK]. A VPLS service instance is also analogous to a
VLAN provided by IEEE 802.1Q networks since each VLAN provides a
Virtual LAN service to its MAC users. Therefore, when a part of the
service provider network is Ethernet based (such as H-VPLS with QinQ
access network), there is a one-to-one correspondence between a VPLS
service instance and its corresponding provider VLAN in the service
provider Ethernet network. To check the end-to-end service
integrity, service level OAM mechanisms are needed.
3.5.2. VPLS as a Network
Sometimes VPLS is also used to refer to the underlying network that
supports bridged LAN services. This network can be an end-to-end
MPLS/IP network as H-VPLS with MPLS/IP access or can be a hybrid
network consisting of MPLS/IP core and Ethernet access network as in
H-VPLS with QinQ access. In either case, the network consists of a
set of VPLS-capable PE devices capable of performing bridging
functions (either full or a subset). These VPLS-capable PE devices
can be arranged in a certain topology such as hierarchical topology
(H-VPLS) or distributed topology (D-VPLS) or some other topologies
such as multi-tier or star topologies. To check the network
integrity regardless of the network topology, network level OAM
mechanisms are needed for the VPLS networks.
3.5.3. VPLS as LAN/VLAN Emulation
Sometimes VPLS also refers to LAN/VLAN emulation. In such context,
VPLS only refers to the full mesh of PWs with split horizon that
emulates a LAN segment over MPLS/IP network for a given service
instance. Since the emulated LAN segment is presented as a Virtual
LAN (VLAN) to the bridge module of a VPLS-capable PE, emulated
segment is also referred to as an emulated VLAN. The OAM mechanisms
in this context refer primarily to integrity check of the full mesh
of PWs and the ability to detect and recover from partial mesh
failure.
When discussing the OAM mechanisms for VPLS, it is important to When discussing the OAM mechanisms for VPLS, it is important to
consider that the end-to-end service can span across different types consider that the end-to-end service can span across different types
of L2VPN networks. As an example, in case of [VPLS-LDP], the access of L2VPN networks. As an example, in case of [VPLS-LDP], the access
network on one side can be bridged network e.g. [IEEE 802.1ad], as network on one side can be bridged network e.g. [IEEE 802.1ad], as
described in section 11 of [VPLS-LDP]. The access network on other described in section 11 of [VPLS-LDP]. The access network on other
side can be MPLS based as described in section 10 of [VPLS-LDP]; and side can be MPLS based as described in section 10 of [VPLS-LDP]; and
the core network connecting them can be IP, MPLS, ATM, or SONET. the core network connecting them can be IP, MPLS, ATM, or SONET.
Similarly, the VPLS service instance can span across [VPLS-BGP], and Similarly, the VPLS service instance can span across [VPLS-BGP], and
distributed VPLS as described in [ROSEN-SIG]. distributed VPLS as described in [ROSEN-SIG].
skipping to change at page 5, line 50 skipping to change at page 8, line 53
all these network types. Each such network may be associated with a all these network types. Each such network may be associated with a
separate administrative domain and also multiple such networks may separate administrative domain and also multiple such networks may
be associated with a single administrative domain. Different types be associated with a single administrative domain. Different types
of pseudo wires may be in use to support end-to-end L2VPNs. of pseudo wires may be in use to support end-to-end L2VPNs.
Therefore, for L2VPN OAM, it is important to ensure that the OAM Therefore, for L2VPN OAM, it is important to ensure that the OAM
mechanisms are independent of the underlying transport mechanisms mechanisms are independent of the underlying transport mechanisms
and solely rely on layer 2 services, e.g. for VPLS service, the and solely rely on layer 2 services, e.g. for VPLS service, the
transparency of OAM mechanisms must be ensured over underlying transparency of OAM mechanisms must be ensured over underlying
transport technologies such as MPLS, IP, etc. transport technologies such as MPLS, IP, etc.
3. OAM Layering This proposal is aligned with the current discussions in other
standard bodies and groups such as ITU-T Q.3/13, IEEE 802.1, and MEF
which are addressing Ethernet network and service OAM.
3.5.4. VPLS OAM Layering
Figure 2 shows an example of a VPLS service (with two CE belonging Figure 2 shows an example of a VPLS service (with two CE belonging
to customer A) across a service provider network marked by UPE and to customer A) across a service provider network marked by UPE and
NPE devices. More CE devices belonging to the same Customer A can be NPE devices. More CE devices belonging to the same Customer A can be
connected across customer's different sites. Service provider connected across different sites of customer. Service provider
network is segmented into core network and two types of access network is segmented into core network and two types of access
network. Figure 2(A) shows the bridged access network represented by network. Figure 2(A) shows the bridged access network represented by
its bridge components marked "B", and the MPLS access and core its bridge components marked "B", and the MPLS access and core
network represented by MPLS components marked "P". Figure 2(B) shows network represented by MPLS components marked "P". Figure 2(B) shows
the service/network view at the Ethernet MAC layer marked by "E". the service/network view at the Ethernet MAC layer marked by "E".
--- --- --- ---
/ \ ------ ------- ---- / \ / \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A | | A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- --- --- --UPE NPE NPE UPE-- ---
skipping to change at page 6, line 31 skipping to change at page 9, line 38
(B) E------E---E--E---E------------E----------E-----E (B) E------E---E--E---E------------E----------E-----E
Figure 2: Service specific device view Figure 2: Service specific device view
As shown in Figure 2(B), only the devices with Ethernet As shown in Figure 2(B), only the devices with Ethernet
functionality are visible to OAM mechanisms operating at Ethernet functionality are visible to OAM mechanisms operating at Ethernet
MAC layer and the P devices are invisible. Therefore, the OAM along MAC layer and the P devices are invisible. Therefore, the OAM along
the path of P devices (e.g., between two PEs) is covered by the path of P devices (e.g., between two PEs) is covered by
transport layer and it is outside the scope of this document. transport layer and it is outside the scope of this document.
3.1. OAM Domains 3.5.5. VPLS OAM Domains
As described in the previous section, a VPLS service for a given As described in the previous section, a VPLS service for a given
customer can span across one or more service providers and network customer can span across one or more service providers and network
operators. Therefore, when discussing OAM tools for VPLS it is operators.
important to provide OAM capabilities and functionality over each
domain that a service provider or a network operator is responsible
for. For these reasons, it is also important that OAM frames are not
allowed to enter/exit other domains. We define an OAM domain as a
network region over which OAM frames operate unobstructed as
explained below.
At the edge of an OAM domain, filtering constructs should prevent
OAM frames from exiting and entering that domain. OAM domains can be
nested but not overlapped. In other words, if there is a hierarchy
of the OAM domains, the OAM messages of a higher-level domain pass
transparently through the lower-level domains but the OAM messages
of a lower-level domain get blocked/filtered at the edge of that
domain.
In order to facilitate the processing of OAM messages, each domain
can be associated with a level at which it operates. Domains with
larger level numbers can contain domain with smaller level numbers
but the converse is not true.
A PE can be part of several domains with each interface belonging to
same or different domains. A PE shall block outgoing OAM messages
and filter out incoming messages whose domain level is lower or
equal to the one configured on that interface and pass through the
messages whose domain level is greater than the one configured on
that interface.
Figure 3 depicts three domains: (A) customer domain which is among Figure 3 depicts three domains: (A) customer domain which is among
the CEs of a given customer, (B) service provider domain which is the CEs of a given customer, (B) service provider domain which is
among the edge PEs of the given service provider, and (C) network among the edge PEs of the given service provider, and (C) network
operator domain which is among the PEs of a given operator. operator domain which is among the PEs of a given operator.
--- --- --- ---
/ \ ------ ------- ---- / \ / \ ------ ------- ---- / \
| CE-- / \ / \ / \ --CE | | CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
skipping to change at page 7, line 25 skipping to change at page 10, line 13
operator domain which is among the PEs of a given operator. operator domain which is among the PEs of a given operator.
--- --- --- ---
/ \ ------ ------- ---- / \ / \ ------ ------- ---- / \
| CE-- / \ / \ / \ --CE | | CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- --- --- --UPE NPE NPE UPE-- ---
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
------ ------- ---- ------ ------- ----
(A) |<----------------------------------------------->| (A) |<----------------------------------------------->|
customer customer
(B) |<---------------------------------->| (B) |<---------------------------------->|
provider provider
(C) |<--------->|<----------->|<-------->| (C) |<--------->|<----------->|<-------->|
operator operator operator operator operator operator
Figure 3: OAM Domains Figure 3: OAM Domains
3.2. MEPs & MIPs 3.5.6. VPLS MEPs & MIPs
Maintenance End Points (MEPs) are responsible for origination and
termination of OAM messages. MEPs are located at the edge of their
corresponding OAM domains. Maintenance Intermediate Points (MIPs)
are located within their corresponding domains and they normally
pass OAM messages but never initiate them. Since MEPs are located at
the edge of their domains, they are responsible for filtering
outbound OAM frames from leaving the domain or inbound OAM frames
from entering the domain. MEPs and MIPs correspond to a PE or more
specifically to an interface of a PE. For example, an OAM message
can be said to originate from an ingress PE or more specifically an
ingress interface of that PE.
Since OAM domains are hierarchical as described above, the MEPs and
MIPs associated with the OAM domains become hierarchical as well. A
MEP of a higher-level domain is always a MEP of a lower-level domain
but the converse is not always true since the MEP of lower-level
domain can either be MIP or a MEP of a higher-level domain.
Furthermore, the MIPs of a lower-level domain are always transparent
to the higher-level domain (e.g., OAM messages of a higher-level As shown in Figure 4, (C) represents those MEPs and MIPs that are
domain are not seen by MIPs of a lower-level domain and get passed visible within the customer domain. (D) represents the MEPs and MIPs
through them transparently). visible within the service provider domain, while (E) represents the
MEPs and MIPs visible within each operator domain. Further, (F)
represents the MEPs and MIPs corresponding to the MPLS layer and may
apply MPLS based mechanisms. The MPLS layer shown in Figure 4 is
just an example and specific OAM mechanisms are outside the scope of
this document.
--- --- --- ---
/ \ ------ ------- ---- / \ / \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A | | A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- --- --- --UPE NPE NPE UPE-- ---
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
------ ------- ---- ------ ------- ----
skipping to change at page 8, line 19 skipping to change at page 10, line 43
--- --- --- ---
/ \ ------ ------- ---- / \ / \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A | | A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- --- --- --UPE NPE NPE UPE-- ---
\ / \ / \ / \ / \ / \ /
\ / \ / \ / \ / \ / \ /
------ ------- ---- ------ ------- ----
(A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE (A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE
(B) E------E---E--E---E------------E----------E-----E (B) E------E---E--E---E------------E----------E-----E
(C) MEP---MIP--------------------------------MIP---MEP (C) MEP---MIP--------------------------------MIP---MEP
Customer Domain Customer Domain
(D) MEP--------MIP-----------MIP-------MEP (D) MEP--------MIP-----------MIP-------MEP
Provider domain Provider domain
(E) MEP-MIP-MIP-MEP----------MEP-------MEP (E) MEP-MIP-MIP-MEP----------MEP-------MEP
Operator Operator Operator Operator Operator Operator
domain domain domain domain domain domain
(F) MEP--MIP-MIP-MEP--MIP--MEP (F) MEP--MIP-MIP-MEP--MIP--MEP
MPLS MPLS MPLS domain MPLS domain
domain domain
Figure 4: OAM Domains, MEPs & MIPs Figure 4: OAM Domains, MEPs & MIPs
As shown in Figure 4, (C) represents those MEPs and MIPs that are 3.5.7. VPLS MEP and MIP Identifiers
visible within the customer domain. (D) represents the MEPs and MIPs
visible within the service provider domain, while (E) represents the
MEPs and MIPs visible within each operator domain. Further, (F)
represents the MEPs and MIPs corresponding to the MPLS layer and may
apply MPLS based mechanisms. The MPLS layer shown in Figure 4 is
just an example and specific OAM mechanisms are outside the scope of
this document.
3.3. MEP and MIP Identifiers
As mentioned previously, L2VPN OAM should be independent of
underlying transport layer and only be dependent on service layer,
e.g. Ethernet MAC layer in case of VPLS service. As an example, for
Ethernet MAC layer, the MEPs and MIPs should be identified with
their Ethernet MAC addresses. As described in [VPLS-LDP], VPLS
instance can be identified in an Ethernet domain (e.g., 8021.d
domain) using VLAN tag (service tag) while in an MPLS/IP network,
PW-ids are used. Both PW-ids and VLAN tags for a given VPLS instance In VPLS, for Ethernet MAC layer, the MEPs and MIPs should be
are associated with a Service Identifier (e.g., VPN identifier). identified with their Ethernet MAC addresses. As described in [VPLS-
MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids must be unique LDP], VPLS instance can be identified in an Ethernet domain (e.g.,
within their corresponding Service Identifiers within the OAM 8021.d domain) using VLAN tag (service tag) while in an MPLS/IP
domains. network, PW-ids are used. Both PW-ids and VLAN tags for a given VPLS
instance are associated with a Service Identifier (e.g., VPN
identifier). MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids
must be unique within their corresponding Service Identifiers within
the OAM domains.
For Ethernet services e.g. VPLS, Ethernet frames are used for OAM For Ethernet services e.g. VPLS, Ethernet frames are used for OAM
messages and the source MAC address of the OAM frames represent the messages and the source MAC address of the OAM frames represent the
source MEP in that domain. For unicast Ethernet OAM frames, the source MEP in that domain. For unicast Ethernet OAM frames, the
destination MAC address represents the destination MEP in that destination MAC address represents the destination MEP in that
domain. For multicast Ethernet OAM frames, the destination MAC domain. For multicast Ethernet OAM frames, the destination MAC
addresses corresponds to all MEPs in that domain. addresses corresponds to all MEPs in that domain.
4. VPLS OAM Requirements 3.6. OAM Framework for VPWS
TBD
4.1. Discovery 3.7. OAM Framework for IPLS
FFS
4. L2VPN OAM Requirements
4.1. VPLS OAM Requirements
4.1.1. Discovery
Discovery allows a service aware device to learn about other devices Discovery allows a service aware device to learn about other devices
that support the same service instance within a given domain. that support the same service instance within a given domain.
Discovery also allows a service aware device to learn sufficient Discovery also allows a service aware device to learn sufficient
information (e.g. IP addresses, MAC addressed etc.) from other information (e.g. IP addresses, MAC addressed etc.) from other
service aware devices such that OAM messages can be exchanged among service aware devices such that OAM messages can be exchanged among
the service aware devices. the service aware devices.
(R1) OAM MUST allow a service aware device to discover other devices (R1) OAM MUST allow a service aware device to discover other devices
that share the same service instance(s) within a given OAM domain. that share the same service instance(s) within a given OAM domain.
4.2. Connectivity Fault Management 4.1.2. Connectivity Fault Management
Service is realized by exchanging service frames/packets between Service is realized by exchanging service frames/packets between
devices that support the service instance. To allow the exchange of devices that support the service instance. To allow the exchange of
service frames, connectivity between these service aware devices is service frames, connectivity between these service aware devices is
required. required.
4.2.1. Connectivity Fault Detection 4.1.3. Connectivity Fault Detection
To ensure service, pro-active connectivity monitoring is required. To ensure service, pro-active connectivity monitoring is required.
Connectivity monitoring facilitates connectivity fault detection. Connectivity monitoring facilitates connectivity fault detection.
(R2a) OAM MUST allow pro-active connectivity monitoring between two (R2a) OAM MUST allow pro-active connectivity monitoring between two
service aware devices that support the same service instance within service aware devices that support the same service instance within
a given OAM domain. a given OAM domain.
4.2.2. Connectivity Fault Verification 4.1.4. Connectivity Fault Verification
Once a connectivity fault is detected, connectivity fault Once a connectivity fault is detected, connectivity fault
verification may be performed. verification may be performed.
(R2b) OAM MUST allow connectivity fault verification between two (R2b) OAM MUST allow connectivity fault verification between two
service aware devices that support the same service instance within service aware devices that support the same service instance within
a given OAM domain. a given OAM domain.
4.2.3. Connectivity Fault Localization 4.1.5. Connectivity Fault Localization
Further, localization of connectivity fault may be carried out. Further, localization of connectivity fault may be carried out.
(R2c) OAM MUST allow connectivity fault localization between two (R2c) OAM MUST allow connectivity fault localization between two
service aware devices that support the same service instance within service aware devices that support the same service instance within
a given OAM domain. a given OAM domain.
4.2.4. Connectivity Fault Alarm 4.1.6. Connectivity Fault Alarm
Typically, when connectivity fault is detected and optionally Typically, when connectivity fault is detected and optionally
verified, service device may notify the EMS/NMS (Element Management verified, service device may notify the EMS/NMS (Element Management
System/Network Management System). System/Network Management System).
However, a single transport/network fault may cause multiple However, a single transport/network fault may cause multiple
services to fail causing multiple connectivity faults. Therefore, services to fail causing multiple connectivity faults. Therefore,
OAM must allow alarm notification to allow suppression of service OAM must allow alarm notification to allow suppression of service
connectivity fault notifications. connectivity fault notifications.
(R2d) OAM MUST allow forwarding of transport/network fault (R2d) OAM MUST allow forwarding of transport/network fault
indications to those service aware devices that support service indications to those service aware devices that support service
instance affected by the fault. instance affected by the fault.
4.3. Frame Loss 4.1.7. Frame Loss
A service may be considered degraded if it is sensitive to service A service may be considered degraded if it is sensitive to service
frames/packets loss during transit between the service aware frames/packets loss during transit between the service aware
devices. To determine if a service is degraded due to frame/packet devices. To determine if a service is degraded due to frame/packet
loss, measurement of frame/packet loss is required. loss, measurement of frame/packet loss is required.
(R3) OAM MUST support measurement of per-service frame/packet loss (R3) OAM MUST support measurement of per-service frame/packet loss
between two service aware devices that support the same service between two service aware devices that support the same service
instance within a given OAM domain. instance within a given OAM domain.
4.4. Frame Delay 4.1.8. Frame Delay
A service may be sensitive to delay experienced by the service A service may be sensitive to delay experienced by the service
frames/packets during transit between the service aware devices. To frames/packets during transit between the service aware devices. To
determine if a service is degraded due to frame/packet delay, determine if a service is degraded due to frame/packet delay,
measurement of frame/packet delay is required. measurement of frame/packet delay is required.
Frame/packet delay measurement can be of two types: Frame/packet delay measurement can be of two types:
One-way delay One-way delay
One-way delay is used to characterize certain applications like One-way delay is used to characterize certain applications like
skipping to change at page 11, line 22 skipping to change at page 13, line 38
experienced. experienced.
(R4a) OAM MUST support measurement of per-service two-way (R4a) OAM MUST support measurement of per-service two-way
frame/packet delay between two service aware devices that support frame/packet delay between two service aware devices that support
the same service instance within a given OAM domain. the same service instance within a given OAM domain.
(R4b) OAM SHOULD support measurement of per-service one-way (R4b) OAM SHOULD support measurement of per-service one-way
frame/packet delay between two service aware devices that support frame/packet delay between two service aware devices that support
the same service instance within a given OAM domain. the same service instance within a given OAM domain.
4.5. Frame Delay Variation 4.1.9. Frame Delay Variation
A service may be sensitive to delay variation experienced by the A service may be sensitive to delay variation experienced by the
service frames/packets during transit between the service aware service frames/packets during transit between the service aware
devices. To determine if a service is degraded due to frame/packet devices. To determine if a service is degraded due to frame/packet
delay variation, measurement of frame/packet delay variation is delay variation, measurement of frame/packet delay variation is
required. For frame/packet delay variation measurements, one-way required. For frame/packet delay variation measurements, one-way
mechanisms are considered to be sufficient. mechanisms are considered to be sufficient.
(R5) OAM MUST support measurement of per-service frame/packet delay (R5) OAM MUST support measurement of per-service frame/packet delay
variation between two service aware devices that support the same variation between two service aware devices that support the same
service instance within a given OAM domain. service instance within a given OAM domain.
4.6. Data Path Execution 4.1.10. Data Path Execution
If the OAM frames flow across a different path than the one used by If the OAM frames flow across a different path than the one used by
service frames/packets, accurate measurement and/or determination of service frames/packets, accurate measurement and/or determination of
service state may not be made. Therefore data path, i.e. the one service state may not be made. Therefore data path, i.e. the one
being taken by service frames/packets, must be used for the service being taken by service frames/packets, must be used for the service
OAM. OAM.
(R6) OAM frames MUST be forwarded along the same path as the (R6) OAM frames MUST be forwarded along the same path as the
service/data frames. service/data frames.
4.7. Scalability 4.1.11. Scalability
Mechanisms developed for OAM need to be such that per-service OAM Mechanisms developed for OAM need to be such that per-service OAM
can be supported even though the OAM may only be used for limited can be supported even though the OAM may only be used for limited
services e.g. premium services and may not be used for best effort services e.g. premium services and may not be used for best effort
services. services.
Note: The specific numbers or range of services should align with Note: The specific numbers or range of services should align with
the [L2VPN-FRWK] the [L2VPN-FRWK]
(R7) OAM MUST be scalable such that a service device can support OAM (R7) OAM MUST be scalable such that a service device can support OAM
for each service that is supported by the device. for each service that is supported by the device.
4.8. Extensibility 4.1.12. Extensibility
Extensibility is intended to allow introduction of additional Extensibility is intended to allow introduction of additional
functionality in future such that backward compatibility can be functionality in future such that backward compatibility can be
maintained i.e. when working with older version devices, service OAM maintained i.e. when working with older version devices, service OAM
with reduced functionality is still possible. with reduced functionality is still possible.
(R8) OAM MUST be extensible such that new functionality and (R8) OAM MUST be extensible such that new functionality and
information elements related to this functionality can be introduced information elements related to this functionality can be introduced
in future. in future.
4.9. Security 4.1.13. Security
OAM frames belonging to an OAM domain originate and terminate within OAM frames belonging to an OAM domain originate and terminate within
that OAM domain. Security implies that an OAM domain must be capable that OAM domain. Security implies that an OAM domain must be capable
of filtering OAM frames. The filtering is such that the OAM frames of filtering OAM frames. The filtering is such that the OAM frames
are prevented from leaking outside their domain. Also, OAM frames are prevented from leaking outside their domain. Also, OAM frames
from outside the OAM domains should be either discarded (when such from outside the OAM domains should be either discarded (when such
OAM frames belong to same or lower-level OAM domain) or OAM frames belong to same or lower-level OAM domain) or
transparently passed (when such OAM frames belong to a higher-level transparently passed (when such OAM frames belong to a higher-level
OAM domain). OAM domain).
skipping to change at page 12, line 41 skipping to change at page 15, line 9
domain. domain.
(R9b) OAM frames from outside an OAM domain MUST be prevented from (R9b) OAM frames from outside an OAM domain MUST be prevented from
entering the OAM domain when such OAM frames belong to the same entering the OAM domain when such OAM frames belong to the same
level or lower-level OAM domain. level or lower-level OAM domain.
(R9c) OAM frames from outside an OAM domain MUST be transported (R9c) OAM frames from outside an OAM domain MUST be transported
transparently inside the OAM domain when such OAM frames belong to transparently inside the OAM domain when such OAM frames belong to
the higher-level OAM domain. the higher-level OAM domain.
4.10. Transport Independence 4.1.14. Transport Independence
Service frame/packets delivery is carried out across transport Service frame/packets delivery is carried out across transport
infrastructure, also called network infrastructure. Though specific infrastructure, also called network infrastructure. Though specific
transport/network technologies may provide their own OAM transport/network technologies may provide their own OAM
capabilities, Service OAM must be independently supported as many capabilities, Service OAM must be independently supported as many
different transport/network technologies can be used to carry different transport/network technologies can be used to carry
service frame/packets. service frame/packets.
(R10a) OAM MUST be independent of the underlying transport/network (R10a) OAM MUST be independent of the underlying transport/network
technologies and specific transport/network OAM capabilities. technologies and specific transport/network OAM capabilities.
(R10b) OAM MAY allow adaptation/interworking with specific (R10b) OAM MAY allow adaptation/interworking with specific
transport/network OAM functions. For example, this would be useful transport/network OAM functions. For example, this would be useful
to allow Fault Notifications from transport/network layer(s) to be to allow Fault Notifications from transport/network layer(s) to be
sent to service layer. sent to service layer.
4.11. Application Independence 4.1.15. Application Independence
Service itself may be used to carry application frame/packets. The Service itself may be used to carry application frame/packets. The
application may use its own OAM; service OAM must not be dependent application may use its own OAM; service OAM must not be dependent
on application OAM. As an example, a VPLS service may be used to on application OAM. As an example, a VPLS service may be used to
carry IP traffic; however, VPLS OAM should not assume IP or rely on carry IP traffic; however, VPLS OAM should not assume IP or rely on
the use of IP level OAM functions. the use of IP level OAM functions.
(R11a) OAM MUST be independent of the application technologies and (R11a) OAM MUST be independent of the application technologies and
specific application OAM capabilities. specific application OAM capabilities.
4.12. Backward Compatibility 4.1.16. Backward Compatibility
Service OAM should be such that non-service aware and/or OAM Service OAM should be such that non-service aware and/or OAM
incapable devices in the middle of the OAM domain should be able to incapable devices in the middle of the OAM domain should be able to
forward the OAM frames similar to the regular service/data forward the OAM frames similar to the regular service/data
frames/packets. frames/packets.
(R12) OAM MUST be defined such that devices not supporting the OAM (R12) OAM MUST be defined such that devices not supporting the OAM
are able to forward the OAM frames in a similar fashion as the are able to forward the OAM frames in a similar fashion as the
regular service/data frames/packets. regular service/data frames/packets.
4.13. Availability 4.1.17. Availability
A service may be considered unavailable if the service A service may be considered unavailable if the service
frames/packets do not reach their intended destination (e.g. frames/packets do not reach their intended destination (e.g.
connectivity is down or frame/packet loss is occurring) or the connectivity is down or frame/packet loss is occurring) or the
service is degraded (e.g. frame/packet delay and/or delay variation service is degraded (e.g. frame/packet delay and/or delay variation
threshold is exceeded). threshold is exceeded).
Entry and exit conditions may be defined for unavailable state. Entry and exit conditions may be defined for unavailable state.
Availability itself may be defined in context of service type. Availability itself may be defined in context of service type.
Since availability measurement may be associated with connectivity, Since availability measurement may be associated with connectivity,
frame/packet loss, frame/packet delay and frame/packet delay frame/packet loss, frame/packet delay and frame/packet delay
variation measurements, no additional requirements are specified variation measurements, no additional requirements are specified
currently. currently.
skipping to change at page 13, line 48 skipping to change at page 16, line 16
threshold is exceeded). threshold is exceeded).
Entry and exit conditions may be defined for unavailable state. Entry and exit conditions may be defined for unavailable state.
Availability itself may be defined in context of service type. Availability itself may be defined in context of service type.
Since availability measurement may be associated with connectivity, Since availability measurement may be associated with connectivity,
frame/packet loss, frame/packet delay and frame/packet delay frame/packet loss, frame/packet delay and frame/packet delay
variation measurements, no additional requirements are specified variation measurements, no additional requirements are specified
currently. currently.
4.2. VPWS OAM Requirements
TBD
4.3. IPLS OAM Requirements
FFS
5. Acknowledgments 5. Acknowledgments
The authors would like to thank Shahram Davari, Norm Finn, Vasile The authors would like to thank Shahram Davari, Norm Finn, Vasile
Radoaca, Thomas Nadeau, and Monique Morrow for their contributions Radoaca, Thomas Nadeau, and Monique Morrow for their contributions
and review. and review.
The authors would also like to thank Yoav Cohen, Marc Holness, The authors would also like to thank Yoav Cohen, Marc Holness,
Malcolm Betts, Paul Bottorff, Dave Allan, and Hamid-ould Brahim for Malcolm Betts, Paul Bottorff, Dave Allan, and Hamid-ould Brahim for
their valuable feedback. their valuable feedback.
skipping to change at line 748 skipping to change at line 847
[VPLS-LDP] "Virtual Private LAN Services over MPLS", [VPLS-LDP] "Virtual Private LAN Services over MPLS",
draft-ietf-l2vpn-vpls-ldp-05.txt, Work in progress, September 2004. draft-ietf-l2vpn-vpls-ldp-05.txt, Work in progress, September 2004.
[VPLS-BGP] "Virtual Private LAN Service", [VPLS-BGP] "Virtual Private LAN Service",
draft-ietf-l2vpn-vpls-bgp-02.txt, Work in progress, May 2004. draft-ietf-l2vpn-vpls-bgp-02.txt, Work in progress, May 2004.
12. Authors' Addresses 12. Authors' Addresses
Dinesh Mohan Dinesh Mohan
Nortel Networks Nortel
3500 Carling Ave 3500 Carling Ave
Ottawa, ON K2H8E9 Ottawa, ON K2H8E9
Email: mohand@nortelnetworks.com Email: mohand@nortel.com
Ali Sajassi Ali Sajassi
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Email: sajassi@cisco.com Email: sajassi@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/