draft-ietf-l2vpn-oam-req-frmk-09.txt   draft-ietf-l2vpn-oam-req-frmk-10.txt 
Internet Draft Document Dinesh Mohan (Editor)
L2VPN Working Group Nortel
Expires: March 2008 Ali Sajassi (Editor)
Cisco Systems
September 2007 Internet-Draft D. Mohan (Editor), Nortel
L2VPN Working Group A. Sajassi (Editor), Cisco
Intended status: Informational
Date Created: July 14, 2008
Expiration Date: January 14, 2009
L2VPN OAM Requirements and Framework L2VPN OAM Requirements and Framework
draft-ietf-l2vpn-oam-req-frmk-09.txt draft-ietf-l2vpn-oam-req-frmk-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire in January 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This draft provides framework and requirements for Layer 2 Virtual This draft provides framework and requirements for Layer 2 Virtual
Private Networks (L2VPN) Operation, Administration and Maintenance Private Networks (L2VPN) Operation, Administration and Maintenance
(OAM). The OAM framework is intended to provide OAM layering across (OAM). The OAM framework is intended to provide OAM layering across
L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN)
tunnels. The requirements are intended to identify OAM requirement tunnels. The requirements are intended to identify OAM requirement
for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if
L2VPN services OAM requirements impose specific requirements on PW L2VPN services OAM requirements impose specific requirements on PW
OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements
are also identified. are also identified.
Conventions used in this document Conventions used in this document
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.
When these key words are used in consideration of RFC 2119, these
key words are used in capitalized form as indicated above.
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo................................................1
Abstract...........................................................1 Abstract...........................................................1
Conventions used in this document..................................1 Conventions used in this document..................................2
1. Introduction....................................................3 1. Introduction....................................................4
1.1 Terminology....................................................5 1.1 Terminology....................................................5
2. L2VPN Services & Networks.......................................5 2. L2VPN Services & Networks.......................................6
3. L2VPN OAM Framework.............................................6 3. L2VPN OAM Framework.............................................7
3.1. OAM Layering..................................................6 3.1. OAM Layering..................................................7
3.2. OAM Domains...................................................7 3.2. OAM Domains...................................................8
3.3. MEPs and MIPs.................................................8 3.3. MEPs and MIPs.................................................9
3.4. MEP and MIP Identifiers.......................................9 3.4. MEP and MIP Identifiers......................................10
4. OAM Framework for VPLS..........................................9 4. OAM Framework for VPLS.........................................10
4.1. VPLS as Service/Network.......................................9 4.1. VPLS as Service/Network......................................10
4.1.1. VPLS as Bridged LAN Service.................................9 4.1.1. VPLS as Bridged LAN Service................................10
4.1.2. VPLS as a Network..........................................10 4.1.2. VPLS as a Network..........................................11
4.1.3. VPLS as (V)LAN Emulation...................................10 4.1.3. VPLS as (V)LAN Emulation...................................11
4.2. VPLS OAM.....................................................10 4.2. VPLS OAM.....................................................11
4.2.1. VPLS OAM Layering..........................................11 4.2.1. VPLS OAM Layering..........................................12
4.2.2. VPLS OAM Domains...........................................12 4.2.2. VPLS OAM Domains...........................................13
4.2.3. VPLS MEPs & MIPs...........................................12 4.2.3. VPLS MEPs & MIPs...........................................13
4.2.4. VPLS MEP and MIP Identifiers...............................13 4.2.4. VPLS MEP and MIP Identifiers...............................14
5. OAM Framework for VPWS.........................................13 5. OAM Framework for VPWS.........................................14
5.1. VPWS as Service..............................................14 5.1. VPWS as Service..............................................15
5.2. VPWS OAM.....................................................14 5.2. VPWS OAM.....................................................15
5.2.1. VPWS OAM Layering..........................................15 5.2.1. VPWS OAM Layering..........................................16
5.2.2. VPWS OAM Domains...........................................16 5.2.2. VPWS OAM Domains...........................................16
5.2.3. VPWS MEPs & MIPs...........................................17 5.2.3. VPWS MEPs & MIPs...........................................18
5.2.4. VPWS MEP and MIP Identifiers...............................18 5.2.4. VPWS MEP and MIP Identifiers...............................20
6. VPLS Service OAM Requirements..................................19 6. VPLS Service OAM Requirements..................................20
6.1. Discovery....................................................19 6.1. Discovery....................................................20
6.2. Connectivity Fault Management................................19 6.2. Connectivity Fault Management................................20
6.2.1. Connectivity Fault Detection...............................19
6.2.2. Connectivity Fault Verification............................20
6.2.3. Connectivity Fault Localization............................20
6.2.4. Connectivity Fault Alarm...................................20
6.3. Frame Loss...................................................20
6.4. Frame Delay..................................................20
6.5. Frame Delay Variation........................................21
6.6. Availability.................................................21
6.7. Data Path Forwarding.........................................22
6.8. Scalability..................................................22
6.9. Extensibility................................................22
6.10. Security....................................................22
6.11. Transport Independence......................................23
6.12. Application Independence....................................23
7. VPWS OAM Requirements..........................................23
7.1. Discovery....................................................24
7.2. Connectivity Fault Management................................24 6.2.1. Connectivity Fault Detection...............................20
7.2.1. Connectivity Fault Detection...............................24 6.2.2. Connectivity Fault Verification............................21
7.2.2. Connectivity Fault Verification............................24 6.2.3. Connectivity Fault Localization............................21
7.2.3. Connectivity Fault Localization............................24 6.2.4. Connectivity Fault Alarm...................................21
7.2.4. Connectivity Fault Alarm...................................25 6.3. Frame Loss...................................................21
7.3. Frame Loss...................................................25 6.4. Frame Delay..................................................22
7.4. Frame Delay..................................................25 6.5. Frame Delay Variation........................................22
7.5. Frame Delay Variation........................................26 6.6. Availability.................................................22
7.6. Availability.................................................26 6.7. Data Path Forwarding.........................................23
7.7. Data Path Forwarding.........................................27 6.8. Scalability..................................................23
7.8. Scalability..................................................27 6.9. Extensibility................................................23
7.9. Extensibility................................................27 6.10. Security....................................................24
7.10. Security....................................................27 6.11. Transport Independence......................................24
7.11. Transport Independence......................................28 6.12. Application Independence....................................24
7.12. Application Independence....................................28 7. VPWS OAM Requirements..........................................25
7.13. Prioritization..............................................28 7.1. Discovery....................................................25
8. VPLS (V)LAN Emulation OAM Requirements.........................29 7.2. Connectivity Fault Management................................25
8.1. Partial-mesh of PWs..........................................29 7.2.1. Connectivity Fault Detection...............................25
8.2. PW Fault Recovery............................................29 7.2.2. Connectivity Fault Verification............................25
8.3. Connectivity Fault Notification..............................30 7.2.3. Connectivity Fault Localization............................26
9. OAM Operational Scenarios......................................30 7.2.4. Connectivity Fault Alarm...................................26
9.1. VPLS OAM Operational Scenarios...............................30 7.3. Frame Loss...................................................26
10. Acknowledgments...............................................31 7.4. Frame Delay..................................................27
11. Security Considerations.......................................31 7.5. Frame Delay Variation........................................27
12. IANA Considerations...........................................32 7.6. Availability.................................................27
13. References....................................................32 7.7. Data Path Forwarding.........................................28
13.1 Normative References.........................................32 7.8. Scalability..................................................28
13.2 Informative References.......................................32 7.9. Extensibility................................................28
14. Authors' Addresses............................................33 7.10. Security....................................................29
15. IPR Disclosure................................................33 7.11. Transport Independence......................................29
16. IPR Notice....................................................33 7.12. Application Independence....................................29
17. Full Copyright Statement......................................34 7.13. Prioritization..............................................30
8. VPLS (V)LAN Emulation OAM Requirements.........................30
8.1. Partial-mesh of PWs..........................................30
8.2. PW Fault Recovery............................................30
8.3. Connectivity Fault Notification..............................31
9. OAM Operational Scenarios......................................31
9.1. VPLS OAM Operational Scenarios...............................31
10. Acknowledgments...............................................32
12. IANA Considerations...........................................33
11. Security Considerations.......................................33
13. References....................................................33
13.1 Normative References.........................................33
13.2 Informative References.......................................34
A1. Appendix 1 - Alternate Management Models......................34 A1. Appendix 1 - Alternate Management Models......................34
A1.1. Alternate Model 1 (Minimal OAM).............................34 A1.1. Alternate Model 1 (Minimal OAM).............................34
A1.2. Alternate Model 2 (Segment OAM Interworking)................35 A1.2. Alternate Model 2 (Segment OAM Interworking)................35
Intellectual Property Statement...................................36
Authors' Addresses................................................36
Full Copyright Statement..........................................37
1. Introduction 1. Introduction
This draft provides framework and requirements for Layer 2 Virtual This draft provides framework and requirements for Layer 2 Virtual
Private Networks (L2VPN) Operation, Administration and Maintenance Private Networks (L2VPN) Operation, Administration and Maintenance
(OAM). (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 commonly
management, commonly abbreviated as "FCAPS" [NM-Standards]: a) Fault abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b)
Performance Management, c) Configuration Management, d) Accounting
Management, b) Performance Management, c) Configuration Management, 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.
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
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
skipping to change at page 4, line 27 skipping to change at page 4, line 41
- Fault Notification - Fault Notification
- Fault Recovery - Fault Recovery
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 the level
device or link. Therefore, a Fault Isolation mechanism is needed in of a given device or link. Therefore, a Fault Isolation mechanism is
Fault Management. Fault Notification mechanism can be used in needed in Fault Management. Fault Notification mechanism can be used
conjunction with Fault Detection mechanism to notify the upstream in conjunction with Fault Detection mechanism to notify the devices
and downstream devices of a fault. For example, when there is a upstream and downstream to the fault detection point. For example,
client/server relationship between two layered networks; Fault when there is a client/server relationship between two layered
Detection at the server layer will require the following Fault networks, Fault Detection at the server layer may result in the
Notification: following Fault Notifications:
- sending a forward Fault Notification from server layer to the - sending a forward Fault Notification from server layer to the
client layer network(s) using the Fault Notification format client layer network(s) using the Fault Notification format
appropriate to the client layer appropriate to the client layer
- sending a backward Fault Notification at server layer, if - sending a backward Fault Notification at server layer, if
applicable, in the reverse direction applicable, in the reverse direction
- sending a backward Fault Notification at client layer, if - sending a backward Fault Notification at client layer, if
applicable, in the reverse direction applicable, in the reverse direction
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 data path using
device redundancy or link redundancy). alternate devices or links (e.g., device redundancy or link
redundancy).
Performance Management deals with mechanism(s) that allow Performance Management deals with mechanism(s) that allow
determining and measuring the performance of network/services under determining and measuring the performance of network/services under
consideration and notification of them. Performance Management can consideration. Performance Management can be used to verify the
be used to verify the compliance to both the service and network compliance to both the service and network level metric
level metric objectives/specifications. Performance Management objectives/specifications. Performance Management typically consists
typically consists of measurement of Performance Parameters e.g. of measurement of performance metrics e.g. Frame Loss, Frame Delay,
Frame Loss, Frame Delay, Frame Delay Variation (aka Jitter) etc Frame Delay Variation (aka Jitter) etc. across managed entities when
across managed entities when the managed entities are in available the managed entities are in available state. Performance Management
state. Performance Management is suspended across unavailable is suspended across unavailable managed entities.
managed entities. This draft introduces some of these performance
parameters.
[L2VPN-FRWK] specifies three different types of Layer 2 VPN (i.e. [L2VPN-FRWK] specifies three different types of Layer 2 VPN
services). These are VPWS, VPLS and IPLS. services. These are VPWS, VPLS and IPLS.
This document provides a description and a reference model for OAM This document provides a reference model for OAM as it relates to
as it relates to L2VPN services and their associated Pseudowires L2VPN services and their associated Pseudo Wires (PWs) and Public
(PWs) and Public Switched Network (PSN) tunnels. The requirements Switched Network (PSN) tunnels. OAM requirement for L2VPN services
are intended to identify OAM requirement for L2VPN services (e.g. (e.g. VPLS and VPWS) are also identified. Furthermore, if L2VPN
VPLS and VPWS). Furthermore, if L2VPN services OAM requirements services OAM requirements impose requirements for PW and/or PSN OAM,
impose specific requirements on PW OAM and/or PSN OAM, those those specific PW and/or PSN OAM requirements are also identified.
specific PW and/or PSN OAM requirements are also identified.
1.1 Terminology 1.1 Terminology
This document introduces and uses the following terms. Further, this This document introduces and uses the following terms. Further, this
document also uses the terms defined in [L2VPN-FRWK]. document also uses the terms defined in [L2VPN-FRWK] and [L2VPN-
TERM].
AIS Alarm Indication Signal AIS Alarm Indication Signal
FM Fault Management FM Fault Management
OAM Domain OAM Domain represents a region over which OAM frames IPLS IP-only LAN Service
can operate unobstructed
ME Maintenance Entity which is defined in a given OAM ME Maintenance Entity which is defined in a given OAM
domain and represents an entity requiring monitoring domain and represents an entity requiring monitoring
MEG Maintenance Entity Group which represents MEs belonging MEG Maintenance Entity Group which represents MEs belonging
to the same service instance. MEG is also called as to the same service instance. MEG is also called as
Maintenance Association (MA). Maintenance Association (MA).
MEP Maintenance End Point is responsible for origination MEP Maintenance End Point is responsible for origination
and termination of OAM frames for a given MEG and termination of OAM frames for a given MEG
MIP Maintenance Intermediate Point is located between peer MIP Maintenance Intermediate Point is located between peer
MEPs and can process OAM frames but does not initiate MEPs and can process OAM frames but does not initiate
or terminate them or terminate them
OAM Domain OAM Domain represents a region over which OAM frames
can operate unobstructed
PM Performance Management PM Performance Management
RDI Remote Defect Indication RDI Remote Defect Indication
SLA Service Level Agreement SLA Service Level Agreement
STP Spanning Tree Protocols STP Spanning Tree Protocols
VPLS Virtual Private LAN Service
VPWS Virtual Private Wire Service
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 |
+-----+ | ..................... | +-----+ +-----+ | ..................... | +-----+
skipping to change at page 11, line 9 skipping to change at page 12, line 9
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 can also described in section 11 of [VPLS-LDP]. The access network can also
be a [IEEE 802.1ah] based bridged network. The access network on be a [IEEE 802.1ah] based bridged network. The access network on
other side can be MPLS based as described in section 10 of [VPLS- other 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 LDP]; and the core network connecting them can be IP, MPLS, ATM, or
SONET. Similarly, the VPLS service instance can span across [VPLS- SONET. Similarly, the VPLS service instance can span across [VPLS-
BGP], and distributed VPLS as described in [ROSEN-SIG]. BGP], and distributed VPLS as described in [L2VPN-SIG].
Therefore, it is important that the OAM mechanisms can be applied to Therefore, it is important that the OAM mechanisms can be applied to
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. It is important be associated with a single administrative domain. It is important
to ensure that the OAM mechanisms are independent of the underlying to ensure that the OAM mechanisms are independent of the underlying
transport mechanisms and solely rely on VPLS service, i.e. the transport mechanisms and solely rely on VPLS service, i.e. 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.
skipping to change at page 14, line 49 skipping to change at page 15, line 49
When discussing the OAM mechanisms for VPWS, it is important to When discussing the OAM mechanisms for VPWS, 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 networks. As an example, the access network between CE and PE on of networks. As an example, the access network between CE and PE on
one side can be Ethernet bridged network, ATM network, etc. In one side can be Ethernet bridged network, ATM network, etc. In
common scenarios, it could simply be a point-to-point interface such common scenarios, it could simply be a point-to-point interface such
as Ethernet PHY. The core network connecting PEs can be IP, MPLS, as Ethernet PHY. The core network connecting PEs can be IP, MPLS,
etc. etc.
Therefore, it is important that the OAM mechanisms can be applied to Therefore, it is important that the OAM mechanisms can be applied to
different network types some of which mentioned above. Each such different network types some of which are mentioned above. Each such
network may be associated with a separate administrative domain and network may be associated with a separate administrative domain and
also multiple such networks may be associated with a single also multiple such networks may be associated with a single
administrative domain. administrative domain.
This proposal is aligned with the current discussions in other
working groups such as PWE3.
5.2.1. VPWS OAM Layering 5.2.1. VPWS OAM Layering
Figure 7 shows an example of a VPWS service (with two CE devices Figure 7 shows an example of a VPWS service (with two CE devices
belonging to customer A) across a service provider network marked by belonging to customer A) across a service provider network marked by
PE devices. Service provider network can be considered to be PE devices. Service provider network can be considered to be
segmented into a core network and two types of access network. segmented into a core network and two types of access network.
In the most general case, a PE can be client service aware when it In the most general case, a PE can be client service aware when it
processes client service PDUs and is responsible for encapsulating processes client service PDUs and is responsible for encapsulating
and de-encapsulating client service PDUs onto PWs and ACs. This is and de-encapsulating client service PDUs onto PWs and ACs. This is
skipping to change at page 17, line 40 skipping to change at page 18, line 36
SP OAM SP OAM SP OAM SP OAM SP OAM SP OAM
(C) |<--------->|<----------------------->|<---------->| (C) |<--------->|<----------------------->|<---------->|
Domain Domain Domain Domain Domain Domain
Operator Operator Operator Operator Operator Operator
(D) |<--------->|<----------------------->|<---------->| (D) |<--------->|<----------------------->|<---------->|
OAM Domain OAM Domain OAM Domain OAM Domain OAM Domain OAM Domain
Figure 8b: VPWS OAM Domains - Management Model 2 Figure 8b: VPWS OAM Domains - Management Model 2
Note: It may be noted that unlike VPLS OAM Domain in Figure 4, where
multiple operator domains may occur between the U-PE devices, VPWS
OAM domain in Figure 8a and 8b highlight a single Operator domain
between PE devices. This is since unlike the distributed VPLS PE
case (H-VPLS) where VPLS service aware U-PEs and N-PEs may be used
to realize a distributed PE, the VPWS has no such distributed PE
model. If the PSN involves multiple Operator domains, resulting in a
Multi-segment PW [Ms-PW Arch], VPWS OAM Domains remain unchanged
since S-PEs are typically not aware of native service.
5.2.3. VPWS MEPs & MIPs 5.2.3. VPWS MEPs & MIPs
The location of MEPs and MIPs can be based upon the management model The location of MEPs and MIPs can be based upon the management model
used in the VPWS scenarios. The interest remains in being able to used in the VPWS scenarios. The interest remains in being able to
monitor end-to-end service and also support segment monitoring in monitor end-to-end service and also support segment monitoring in
the network to allow isolation of faults to specific areas within the network to allow isolation of faults to specific areas within
the network. the network.
The end-to-end service monitoring is provided by end-to-end ME and The end-to-end service monitoring is provided by end-to-end ME and
additional segment OAM monitoring is provided by segment MEs, all in additional segment OAM monitoring is provided by segment MEs, all in
skipping to change at page 18, line 47 skipping to change at page 20, line 4
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| | | |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
+----+ PSN Tunnel +----+ +----+ PSN Tunnel +----+
(B1) MEP-----------------------------------------------MEP (B1) MEP-----------------------------------------------MEP
(B2) MEP----------MIP---------------------MIP----------MEP (B2) MEP----------MIP---------------------MIP----------MEP
(C) MEP-------MEP|MEP------------------MEP|MEP--------MEP (C) MEP-------MEP|MEP------------------MEP|MEP--------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure 9: VPWS MEPs & MIPs Figure 9: VPWS MEPs & MIPs
5.2.4. VPWS MEP and MIP Identifiers 5.2.4. VPWS MEP and MIP Identifiers
In VPWS, the MEPs and MIPs should be identified with their native In VPWS, the MEPs and MIPs should be identified with their native
addressing schemes. MEPs and MIPs Identifiers, i.e. MEP Ids and MIP addressing schemes. MEPs and MIPs Identifiers, i.e. MEP Ids and MIP
Ids, must be unique within their corresponding OAM domains and must Ids, must be unique within their corresponding OAM domains and must
also be unique to the VPWS service instance. also be unique to the VPWS service instance.
6. VPLS Service OAM Requirements 6. VPLS Service OAM Requirements
These requirements are applicable to VPLS as a Bridged LAN service, These requirements are applicable to VPLS PE offering VPLS as an
as described in Section 4.1.1. Further, the performance metrics used Ethernet Bridged LAN service, as described in Section 4.1.1.
in requirements are based on [MEF10] and [RFC2544]. Further, the performance metrics used in requirements are based on
[MEF10.1] and [RFC2544].
It is noted that OAM solutions that meet the following requirements It is noted that OAM solutions that meet the following requirements
may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, etc. may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, etc.
however must not break these existing OAM mechanisms. If extensions however must not break these existing OAM mechanisms. If extensions
are required to existing OAM mechanisms, these should be coordinated are required to existing OAM mechanisms, these should be coordinated
with relevant groups responsible for these OAM mechanisms. with relevant groups responsible for these OAM mechanisms.
6.1. Discovery 6.1. Discovery
Discovery allows a VPLS service aware device to learn about other Discovery allows a VPLS service aware device to learn about other
skipping to change at page 23, line 50 skipping to change at page 25, line 7
The application may use its own OAM; service OAM must not be The application may use its own OAM; service OAM must not be
dependent on application OAM. As an example, a VPLS service may be dependent on application OAM. As an example, a VPLS service may be
used to carry IP traffic; however, VPLS OAM should not assume IP or used to carry IP traffic; however, VPLS OAM should not assume IP or
rely on the use of IP level OAM functions. rely on the use of IP level OAM functions.
(R11a) VPLS OAM MUST be independent of the application technologies (R11a) VPLS OAM MUST be independent of the application technologies
and specific application OAM capabilities. and specific application OAM capabilities.
7. VPWS OAM Requirements 7. VPWS OAM Requirements
The performance metrics used in requirements are based on [MEF10] These requirements are applicable to VPWS PE. The performance
and [RFC2544]. metrics used in requirements are based on [MEF10.1] and [RFC2544],
which are applicable to Ethernet Services.
It is noted that OAM solutions that meet the following requirements It is noted that OAM solutions that meet the following requirements
may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, etc. may make use of existing OAM mechanisms e.g. Ethernet OAM, VCCV, etc.
however must not break these existing OAM mechanisms. If extensions however must not break these existing OAM mechanisms. If extensions
are required to existing OAM mechanisms, these should be coordinated are required to existing OAM mechanisms, these should be coordinated
with relevant groups responsible for these OAM mechanisms. with relevant groups responsible for these OAM mechanisms.
7.1. Discovery 7.1. Discovery
Discovery allows a VPWS service aware device to learn about other Discovery allows a VPWS service aware device to learn about other
devices that support the same VPWS service instance within a given devices that support the same VPWS service instance within a given
domain. Discovery also allows a VPWS service aware device to learn domain. Discovery also allows a VPWS service aware device to learn
sufficient information (e.g. IP addresses, MAC addresses etc.) from sufficient information (e.g. IP addresses, MAC addresses etc.) from
skipping to change at page 30, line 16 skipping to change at page 31, line 25
fault recovery time in the provider OAM domain faster than the VPLS fault recovery time in the provider OAM domain faster than the VPLS
fault recovery time in the customer OAM domain. fault recovery time in the customer OAM domain.
8.3. Connectivity Fault Notification 8.3. Connectivity Fault Notification
When connectivity fault is detected in (V)LAN emulation, PE devices When connectivity fault is detected in (V)LAN emulation, PE devices
may notify the NMS (Network Management System). However, a single may notify the NMS (Network Management System). However, a single
(V)LAN emulation fault may result in CE devices or U-PE devices (V)LAN emulation fault may result in CE devices or U-PE devices
detecting connectivity fault in VPLS service and therefore also detecting connectivity fault in VPLS service and therefore also
notifying the NMS. To prevent multiple notifications for the same notifying the NMS. To prevent multiple notifications for the same
fault, (V)LAN emulation OAM should provide alarm suppression fault, (V)LAN emulation OAM must provide alarm suppression
capability in the VPLS service OAM. capability in the VPLS service OAM.
(R15) PW OAM for PWs related to a (V)LAN emulation MUST support (R15) PW OAM for PWs related to a (V)LAN emulation MUST support
interworking with VPLS service OAM to allow alarm suppression in the interworking with VPLS service OAM to allow alarm suppression in the
VPLS service upon fault detection in (V)LAN emulation. VPLS service upon fault detection in (V)LAN emulation.
9. OAM Operational Scenarios 9. OAM Operational Scenarios
This section highlights how the different OAM mechanisms can be This section highlights how the different OAM mechanisms can be
applied as per the OAM framework for different L2VPN services. applied as per the OAM framework for different L2VPN services.
skipping to change at page 31, line 17 skipping to change at page 32, line 26
mechanisms can be applied, to meet various requirements identified mechanisms can be applied, to meet various requirements identified
in Section 6. The mechanisms can be applied across Figure 10 (C) in Section 6. The mechanisms can be applied across Figure 10 (C)
MEs. MEs.
Similarly, inside the Service Provider OAM domain, [IEEE 802.1ag] Similarly, inside the Service Provider OAM domain, [IEEE 802.1ag]
and [Y.1731] Ethernet OAM mechanisms can be applied across Figure 10 and [Y.1731] Ethernet OAM mechanisms can be applied across Figure 10
(D) MEs to meet functional requirements identified in Section 6. (D) MEs to meet functional requirements identified in Section 6.
It may be noted that in the interim, when [IEEE 802.1ag] and It may be noted that in the interim, when [IEEE 802.1ag] and
[Y.1731] capabilities are not available across the PE devices, the [Y.1731] capabilities are not available across the PE devices, the
management option introduced in Section 5.2.3.2 can be applied, with management option introduced in Section 5.2.3 can be applied, with
the limitations cited below. In this option, the Service Provider the limitations cited below. In this option, the Service Provider
can run segment OAM across the Figure 10 (D1) MEs. The OAM can run segment OAM across the Figure 10 (D1) MEs. The OAM
mechanisms across the Figure 10 (D1) MEs can be non-Ethernet e.g. mechanisms across the Figure 10 (D1) MEs can be non-Ethernet e.g.
VCCV, or BFD when network technology is MPLS. The Service Provider VCCV, or BFD when network technology is MPLS. The Service Provider
can monitor each sub-network segment ME using the native technology can monitor each sub-network segment ME using the native technology
OAM and by performing interworking across the segment MEs, attempt OAM and by performing interworking across the segment MEs, attempt
to realize end-to-end monitoring between a pair of VPLS end-points. to realize end-to-end monitoring between a pair of VPLS end-points.
However, such mechanisms do not fully utilize the data plane However, such mechanisms do not fully utilize the data plane
forwarding as experienced by native (i.e. Ethernet) service PDUs and forwarding as experienced by native (i.e. Ethernet) service PDUs and
therefore monitoring is severely limited in the sense that therefore monitoring is severely limited in the sense that
skipping to change at page 31, line 52 skipping to change at page 33, line 10
The authors would like to thank Deborah Brungard, Vasile Radoaca, The authors would like to thank Deborah Brungard, Vasile Radoaca,
Lei Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their Lei Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their
reviews and comments. reviews and comments.
Authors would also like to thank Shahram Davari, Norm Finn, Dave Authors would also like to thank Shahram Davari, Norm Finn, Dave
Allan, Thomas Nadeau, Monique Morrow, Yoav Cohen, Marc Holness, Allan, Thomas Nadeau, Monique Morrow, Yoav Cohen, Marc Holness,
Malcolm Betts, Paul Bottorff, Hamid-ould Brahim, Lior Shabtay, and Malcolm Betts, Paul Bottorff, Hamid-ould Brahim, Lior Shabtay, and
Dan Cauchy for their feedback. Dan Cauchy for their feedback.
11. Security Considerations
This document does not impose any security concerns since it imposes
requirements on solutions to prevent OAM messages from leaking
outside the OAM domains. For additional levels of security, the
solutions may be required deploy to encrypt and/or authenticate OAM
frames inside an OAM domain however solutions are out of the scope
of this draft.
12. IANA Considerations 12. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
13. References 11. Security Considerations
13.1 Normative References
[NM-Standards] "TMN Management Functions", M.3400, February 2000.
[MEF10] "Ethernet Services Attributes: Phase 1", MEF 10, 2004.
[Y.1731] "OAM Functions and mechanisms for Ethernet based networks", This document takes into account the security considerations and
ITU-T Y.1731, May 2006. imposes requirements on solutions to prevent OAM messages from
leaking outside an OAM domain and for OAM domains to be transparent
to OAM frames from higher OAM domains, as specified in Section 6.10
and 7.10.
[VPLS-LDP] "Virtual Private LAN Services over MPLS", RFC 4762, Jan For additional levels of security, the solutions may be required to
2007. encrypt and/or authenticate OAM frames inside an OAM domain however
solutions are out of the scope of this draft.
[VPLS-BGP] "Virtual Private LAN Service", RFC 4761, Jan 2007. 13. References
[IEEE 802.1ad] "IEEE standard for Provider Bridges", July 2005. 13.1 Normative References
13.2 Informative References [IEEE 802.1ad] "IEEE Standard for Local and metropolitan area
networks - virtual Bridged Local Area Networks, Amendment 4:
Provider Bridges", 2005
[RFC2544] "Benchmarking Methodology for Network Interconnect [IEEE 802.1ag] "IEEE Standard for Local and metropolitan area
Devices", RFC 2544, 1999. networks - virtual Bridged Local Area Networks, Amendment 5:
Connectivity Fault Management", 2007
[L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned [IEEE 802.1ah] "IEEE Standard for Local and metropolitan area
Virtual Private Networks", RFC 4665. networks - virtual Bridged Local Area Networks, Amendment 6:
Provider Backbone Bridges", 2008
[L2VPN-FRWK] "Framework for Layer 2 Virtual Private Networks [L2VPN-FRWK] "Framework for Layer 2 Virtual Private Networks
(L2VPNs)", RFC 4664. (L2VPNs)", RFC 4664
[IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", Work
in Progress, July 2005.
[ROSEN-SIG] "Provisioning Models and Endpoint Identifiers in L2VPN
Signaling", draft-ietf-l2vpn-signaling-02.txt, Work in progress,
September 2004.
[BRIDGE-INTEROP] "VPLS Interoperability with CE Bridges", draft-
sajassi-l2vpn-vpls-bridge-interop-01.txt, Work in progress, July
2005.
14. Authors' Addresses
Dinesh Mohan
Nortel
3500 Carling Ave
Ottawa, ON K2H8E9
Email: mohand@nortel.com
Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: sajassi@cisco.com
Simon Delord
Uecomm
658 Church St
Richmond, VIC, 3121, Australia
E-mail: sdelord@uecomm.com.au
Philippe Niger
France Telecom
2 av. Pierre Marzin
22300 LANNION, France
E-mail: philippe.niger@francetelecom.com
15. IPR Disclosure [L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned
Virtual Private Networks", RFC 4665
This document is submitted for IETF purposes. [L2VPN-TERM] "Provider Provisioned Virtual Private Network (VPN)
Terminology", RFC 4026
16. IPR Notice [MEF10.1] "Ethernet Services Attributes: Phase 2", MEF 10.1, 2006
The IETF takes no position regarding the validity or scope of any [NM-Standards] "TMN Management Functions", M.3400, February 2000
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 [VPLS-LDP] "Virtual Private LAN Services over MPLS", RFC 4762, Jan
assurances of licenses to be made available, or the result of an 2007
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 [Y.1731] "OAM Functions and mechanisms for Ethernet based networks",
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any 13.2 Informative References
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.
17. Full Copyright Statement [BRIDGE-INTEROP] "VPLS Interoperability with CE Bridges", draft-
ietf-l2vpn-vpls-bridge-interop-02.txt, Work in progress, November
2007
Copyright (C) The IETF Trust (2007). [L2VPN-SIG] "Provisioning, Autodiscovery, and Signaling in L2VPNs",
This document is subject to the rights, licenses and restrictions [MS-PW Arch] "An Architecture for Multi-segment Pseudowire Emulation
contained in BCP 78, and except as set forth therein, the authors Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-04.txt, Work in progress,
retain all their rights.
This document and the information contained herein are provided on [RFC2544] "Benchmarking Methodology for Network Interconnect
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Devices", RFC 2544, 1999
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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.
A1. Appendix 1 - Alternate Management Models A1. Appendix 1 - Alternate Management Models
In consideration of the management models that can be deployed In consideration of the management models that can be deployed
besides the hierarchical models elaborated in this document, this besides the hierarchical models elaborated in this document, this
section highlights some alternate models that are not recommended section highlights some alternate models that are not recommended
due to their limitations, as pointed out below. These alternatives due to their limitations, as pointed out below. These alternatives
have been highlighted as potential interim models while the network have been highlighted as potential interim models while the network
equipments are upgraded to support full functionality and meet the equipments are upgraded to support full functionality and meet the
requirements set forward by this document. requirements set forward by this document.
skipping to change at line 1744 skipping to change at page 36, line 18
+----+ | |==================| | +----+ +----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| | | |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 | | CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+ +----+ | |==================| | +----+
+----+ PSN Tunnel +----+ +----+ PSN Tunnel +----+
(C) MEP-------MEP|MEP------------------MEP|MEP--------MEP (C) MEP-------MEP|MEP------------------MEP|MEP--------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP (D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure A1.2: VPWS MEPs & MIPs - Segment OAM Interworking Figure A1.2: VPWS MEPs & MIPs - Segment OAM Interworking
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Authors' Addresses
Dinesh Mohan
Nortel
3500 Carling Ave
Ottawa, ON K2H8E9
Email: mohand@nortel.com
Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Email: sajassi@cisco.com
Simon Delord
Uecomm
658 Church St
Richmond, VIC, 3121, Australia
E-mail: sdelord@uecomm.com.au
Philippe Niger
France Telecom
2 av. Pierre Marzin
22300 LANNION, France
E-mail: philippe.niger@francetelecom.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE
IETF TRUST 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.
 End of changes. 60 change blocks. 
237 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/