Technical Specification
MEF XXX
Requirements for Service
Protection Across External Interfaces
Draft 0.4
January 2011
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the Metro Ethernet Forum (MEF) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No
representation or warranty, expressed or implied, is made by the MEF concerning the
completeness, accuracy, or applicability of any information contained herein and no liability of
any kind shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this
document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
any express or implied license or right to or under any patent, copyright, trademark or trade
secret rights held or claimed by any MEF member company which are or may be associated with
the ideas, techniques, concepts or expressions contained herein; nor
any warranty or representation that any MEF member companies will announce any product(s)
and/or service(s) related thereto, or if such announcements are made, that such announced
product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained
herein; nor
any form of relationship between any MEF member companies and the recipient or user of this
document.
Implementation or use of specific Metro Ethernet standards or recommendations and MEF
specifications will be voluntary, and no company shall be obliged to implement them by virtue of
participation in the Metro Ethernet Forum. The MEF is a non-profit international organization
accelerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly or
otherwise, endorse or promote any specific products or services.
© The Metro Ethernet Forum 2010. All Rights Reserved.
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Editor
Yoav Cohen
Contributors
Michael Bugenhagen
Bill Bjorkman
Steve Haddock
Bob Klessig
Raghu Ranganathan
Cherng Yeh
Lionel Florit
Enrique HernandezValencia
Shobhan Ayyadevara
Michael Waldo
Norman Finn
David Allan
Jack Pugaczewski
Company
Nokia Siemens
Networks
Company
Telephone
Email
Yoav.cohen@nsn.com
Telephone
Email
CenturyLink
Verizon
Extreme Networks
MEF
Ciena
Tata
Communications
Cisco
Alcatel-Lucent
Vitesse
Adva
Cisco
Ericsson
Qwest
To be removed when LB approved.
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Requirements for Service Protection Across EIs – Phase 1
Table of Contents
1.
Abstract ................................................................................................................................ 1
2.
Abbreviations ...................................................................................................................... 1
3.
Introduction ......................................................................................................................... 2
4.
Scope and definitions .......................................................................................................... 2
4.1
Definitions ......................................................................................................................... 2
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.1.7
4.1.8
4.2
4.3
4.4
Service End Point (EP)............................................................................................................ 2
Link Connection ...................................................................................................................... 3
Working Link .......................................................................................................................... 3
Protection Link ........................................................................................................................ 3
Active and Standby Links ....................................................................................................... 3
Protection Switching ............................................................................................................... 3
Failure ..................................................................................................................................... 4
Interconnection Zone .............................................................................................................. 4
Reference model ................................................................................................................ 4
In Scope for Phase I ........................................................................................................... 5
Out of Scope for Phase I .................................................................................................... 5
5.
Compliance Levels .............................................................................................................. 5
6.
Requirements....................................................................................................................... 6
6.1
6.2
6.3
General Requirements ....................................................................................................... 6
Requirements addressing Ethernet Layer .......................................................................... 7
Requirements addressing triggers for recovery actions ..................................................... 8
6.3.1
6.4
6.5
7.
Requirements addressing operator manual commands ........................................................... 8
Requirements addressing configuration aspects ................................................................ 8
Requirements for scalability and performance .................................................................. 9
References .......................................................................................................................... 11
8.
Appendix A – Several Operator Networks and their Associated Interconnection
Zones (Informative) .................................................................................................................... 12
List of Figures
Figure 1: A Reference Model of the Interconnection Zones .......................................................... 5
Figure 2 : Example of an EVC traversing several Operators' Networks and Interconnection
Zones ..................................................................................................................................... 12
List of Tables
Table 1: Abbreviations .................................................................................................................... 2
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page i
Requirements for Service Protection Across EIs – Phase 1
1
1.
Abstract
2
3
4
5
The requirements listed in this specification address a gap in the industry specifications that
does not define a protection mechanism without single point of failure for protecting services
at External Interfaces (EIs). That is, there is currently no standard way of protecting the
services at the External Interfaces in case of node failure.
6
7
8
9
10
11
This specification specifies requirements for protecting any MEF Service by protecting its
Service End Points, which associate services with External Interfaces. The requirements
specified in this specification address potential impact on MEF services. MEF would like
these requirements to be considered when designing a mechanism for Service Protection
across an External Interface. The mechanism is assumed to be developed outside MEF by
SDOs such as IEEE 802.1, ITU-T, IETF, etc.
12
13
14
The current MEF standardized External Interfaces are the UNI and ENNI. These
requirements aim to cover a wide range of MEF Ethernet service types as well as a wide
range of packet network deployments in which the EIs are MEF defined EIs.
itor Note
15 1: Editor's notes:
itor Note
16 2: 1. Protection vs. Resiliency: During the Q1/2011 meeting, the Technical
17
Committee agreed to use the term "Resiliency" instead of "Protection".
18
This change would be reflected in the next draft version.
itor Note
19 3: 2. Number of Service End Points per EVC/OVC at an EIs: Single logical
20
view vs. 2 physical location view of the External Interface. This topic
21
is under discussion. A resolution must be reached until the next MEF
22
meeting (Q2/2011).
23
24
25
2.
Abbreviations
Abbreviation
BW
CE
CEN
CoS
EI
EP
EPL
EVC
EVPL
EP-LAN
EVP-LAN
EP-Tree
EVP-Tree
FD
FDV
FLR
MEN
OVC
SLA
MEF xx
Definition
Bandwidth
Customer Edge
Carrier Ethernet Network
Class of Service
External Interface
End Point
Ethernet Private Line
Ethernet Virtual Connection
Ethernet Virtual Private Line
Ethernet Private LAN
Ethernet Virtual Private LAN
Ethernet Private Tree
Ethernet Virtual Private Tree
Frame Delay
Frame Delay Variation
Frame Loss Ratio
Metro Ethernet Network
Operator Virtual Connection
Service Level Agreement
Reference
[5]
[4]
[10]
[10]
[4]
[4]
[4]
[4]
[4]
[4]
[4]
[5]
[5]
[5]
[3]
[10]
[5]
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 1
Requirements for Service Protection Across EIs – Phase 1
Abbreviation
Definition
Standard Development Organization
Service Providers
User Network Interface
Virtual LAN
SDO
SP
UNI
VLAN
26
Reference
[5]
[5]
[5]
Table 1: Abbreviations
27
3.
Introduction
28
29
30
31
32
Reliability, in terms of availability, is a key attribute of a Carrier Ethernet service. High
Availability commitments in SLAs require a resilient network that can rapidly detect
interface failure, node failure and performance degradation, and can rapidly restore service
operation. Network survivability plays a critical factor in the delivery of reliable services.
33
34
35
36
37
38
This specification specifies requirements for protecting any MEF Service by protecting its
Service End Points, which associate services with External Interfaces. The requirements
specified in this specification address potential impact on MEF services. MEF would like
these requirements to be considered when designing a mechanism for Service Protection
across an External Interface. The mechanism is assumed to be developed outside MEF by
SDOs such as IEEE 802.1, ITU-T, IETF, etc.
39
40
41
42
Many protection switching schemes are deployed to date. Those include linear schemes such
as 1:1, 1+1, 1:N as well as protection schemes that operate over Mesh and Ring topologies.
Each of the schemes has its pros and cons. The choice of protection scheme is left to the
discretion of the SDO developing the protection switching mechanism.
43
4.
44
45
46
The scope of this specification reflects the ambitions for specifying requirements for Service
End Point protection across External Interfaces. The requirements for protection address only
the Interconnection Zone (see definition below).
47
4.1
48
49
50
Networks are connected to each other at demarcation points. In many cases the resources
supporting the connections, i.e., nodes and Link Connections (see definition below) are
redundant, providing improved protection for Service End Points.
51
52
This specification defines requirements for protection of Ethernet Service End Points that
would only be performed at the External Interfaces.
Scope and definitions
Definitions
53
54
4.1.1
55
56
57
58
In this specification, a Service End Point is an association of a service or a service constructs
(EVC or OVC) to an External Interface (a UNI or ENNI in the context of this specification).
Note that the End Point normative definition, as specified in the ENNI specification [10],
allows the association of End Points only with OVCs. However, since a given OVC can
MEF xx
Service End Point (EP)
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 2
Requirements for Service Protection Across EIs – Phase 1
59
60
61
62
associate at most one OVC End Point at a given UNI, this specification extends the definition
of an End Point, as specified in the ENNI specification [10], to implicitly assume association
of a single End Point with an EVC at a given UNI [5], as well. Hence the term Service End
Point.
63
4.1.2
64
65
66
67
A Link Connection as defined in [3] denotes the connectivity supporting the exchange of
Ethernet Service Frames or ENNI Frames as defined in [5] and [10], respectively, between
EI peers. The transport layer could be an Ethernet phy sub-layer, Link Aggregation [14] or
any other transport, e.g., MPLS/PW.
68
4.1.3
69
70
The designated Link Connection configured to exchange Ethernet frames between Service
End Points under normal condition (i.e., where there is no failure).
71
4.1.4
72
73
The designated Link Connection configured to exchange Ethernet frames between Service
End Points when the Working Link Connection fails.
74
4.1.5
75
76
Active Link Connection is a dynamic status of a Link Connections indicating that the Link
Connection exchanges Ethernet frames.
77
78
Standby Link Connection is a dynamic status of a Link Connections indicating that the Link
Connection blocks Ethernet frames.
Link Connection
Working Link
Protection Link
Active and Standby Links
79
80
81
Note that the Working Link Connection and the Protection Link Connection can each have a
status of Active or Standby.
82
83
4.1.6
84
85
86
A Protection Switching event occurs when a failure of the Active Link Connection is
detected, and as a result, traffic is switched (i.e., redirected) from the failed Link Connection
to the Standby Link Connection (which now becomes the Active Link Connection).
87
Typically, the Protection Switching is performed by a Protection Switching Mechanism.
Protection Switching
88
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 3
Requirements for Service Protection Across EIs – Phase 1
89
4.1.7
90
91
Throughout this specification the term failure means any event that affects an SLA. Examples
of such events are: link failure, node failure, link degradation.
Failure
92
93
4.1.8
94
95
96
97
The area between External Interface peers containing a collection of nodes and Link
Connections, which are assigned to a specific instance of the protection switching
mechanism. The Interconnection Zones currently supported by MEF Specifications are: UNI,
i.e., between UNI-C and UNI-N, and ENNI, between adjacent ENNI-Ns.
98
99
Note that other nodes and Link Connections supporting External Interfaces may be assigned
to other Interconnection Zones or not assigned to any Interconnection Zone.
Interconnection Zone
100
4.2
Reference model
101
102
103
104
105
106
107
The network reference model is illustrated in Figure 1 below. Several adjacent MENs/CENs
for which protection requirements may be defined, are illustrated in the figure. The
Interconnection Zones currently supported by MEF Specifications are: UNI i.e., between
UNI-C and UNI-N and ENNI between adjacent ENNI-Ns. This reference model is used when
defining requirements for Service End Point protection and related terminology.
108
Subscriber
Premise
Subscriber
Premise
Operator 1
Network
UNI
Interconnection
Zone
ENNI
Interconnection
Zone
Operator 2
Network
ENNI
Interconnection
Zone
109
110
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 4
Requirements for Service Protection Across EIs – Phase 1
111
112
Figure 1: A Reference Model of the Interconnection Zones
113
Several MENs/CENs and subscriber premises are depicted in Figure 1. An Interconnection
114
Zone may be defined between two adjacent networks supporting MEF defined ENNI
115
External Interfaces or between a MEN and a subscriber premise supporting MEF defined
116
UNI External Interfaces.
117
118
Appendix A depicts a typical use case where an EVC traverses several networks which are
119
interconnected at Interconnection Zones. Each Interconnection Zone provides protection only
120
within its Zone.
121
122
4.3
In Scope for Phase I
123
The following items highlight the scope of this specification for Phase I:
124

ENNI Interconnection Zone
125

UNI Interconnection Zone
126
4.4
Out of Scope for Phase I
127
128
The following are out of scope of this specification for Phase I, but are candidates for
inclusion in Phase II:
129
130

Explore requirements for UTA Service protection across ENNI
Interconnection Zone
131

Explore requirements for NID to MEN Interconnection Zone
132
133
134
135

The requirements listed in this specification assume that the protection
schemes are not based on 1+1. The 1+1 scheme is currently Out Of Scope of
this specification.
136
5.
Compliance Levels
137
138
139
140
141
142
143
144
145
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in IETF RFC 2119 [1].
Items that are REQUIRED (contain the words MUST or MUST NOT) will be labeled as
[Rx] for required. Items that are RECOMMENDED (contain the words SHOULD or
SHOULD NOT) will be labeled as [Dx] for desirable. Items that are OPTIONAL (contain
the words MAY or OPTIONAL) will be labeled as [Ox] for optional.
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 5
Requirements for Service Protection Across EIs – Phase 1
146
6. Requirements
147
148
149
150
151
152
153
154
155
In addressing the reliability requirements for Carrier Ethernet services at the Interconnection
Zone, it is essential that the Interconnection Zone be equipped with a protection mechanism
that is capable of rapidly detecting a failure or facility degradation (node or interface) and of
restoring traffic without impacting EVC SLA provided to the end user. The mechanism
should provide a means to avoid a potential single point failure or an SLA violation such as
high FLR or FD (node or interface).
The designed protection mechanism used in an Interconnection Zone should be robust
enough to ensure a service is protected against various types of failures such as:
156
157

An interface failure between two nodes, each residing on a different Operator
networks
158
159
160

A node failure supporting the service in the Interconnection Zone. Note that as
a corollary another Service End Point may be required to protect the failed
Service End Point.
161
162
163
164
165

Service performance degradation, i.e., where the network performance violates
the SLA, across the Interconnection Zone.
This specification defines requirements for protecting Service End Points (EPs) in the
Interconnection Zone following the topics depicted below:
166
6.1
167
This section details general requirements.
General Requirements
168
[R1]
The protection switching mechanism MUST be able to operate at a UNI.
169
170
[R2]
The protection switching mechanism MUST be able to operate at an
ENNI.
171
172
[R3]
The protection switching mechanism MUST support protection switching
granularity per Service End Point.
173
174
175
176
[R4]
Each Service End Point traffic MUST NOT be split between Link
Connections in the Interconnection Zone.
Note that this requirement is designed to prevent services from being split into "streams" (or
"conversation", as defined in the IEEE 802.3 specification).
177
178
179
180
181
182
183
[R5]
If node protection is required, the protection switching mechanism MUST
be able to support at least two nodes on one side of the UNI reference
point at the Interconnection Zone.
Note that a typical deployment would create a "dual homing" connectivity
between a UNI-C and e.g. 2 UNI-Ns, each residing on a separate node.
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 6
Requirements for Service Protection Across EIs – Phase 1
184
185
186
187
[R6]
The protection switching mechanism MUST support automatic protection
switching from the Working Link Connection to the Protection Link
Connection and from the Protection Link Connection to the Working Link
Connection, in the Interconnection Zone, in case of a failure.
188
189
190
[R7]
If node protection is required, the protection switching mechanism MUST
be able to support at least two nodes on each side of the ENNI reference
point at the Interconnection Zone.
191
192
193
[R8]
Each protected Service End Point MUST be supported by exactly one
Working Link Connection and at least one Protection Link Connection
across the Interconnection Zone.
194
195
196
[R9]
The protection switching mechanism MUST provide indication of the
protection state to a Management Entity, i.e., which Link Connection is
Active for each Service End Point at any given time.
197
198
199
[R10] The protection switching mechanism MUST perform protection switching
at both ends of the Link Connection such that the traffic MUST ingress
and egress through the same Service End Points.
200
201
202
203
204
205
206
207
208
209
210
[R11] In the absence of any other failure, the protection switching mechanism
MUST be capable of protecting at least against a single node failure within
the Interconnection Zone.
211
212
213
[R12] In the absence of any other failure, the protection switching mechanism
MUST protect at least against a single Link Connection failure within the
Interconnection Zone.
214
215
216
[R13] The protection switching mechanism MUST be decoupled from the
networks it is adjacent to and SHOULD be able to perform all its
functionality independent of the adjacent networks' internal functionality.
217
218
219
220
[R14] The protection switching mechanism MUST support Service Frames
(comprising C-Tags, priority tag and untagged Ethernet frames) at the UNI
reference point, as defined in the MEF 10.2, “Ethernet Services Attributes
- Phase 2” [10].
221
222
[R15] The protection switching mechanism MUST provide indication of the
protection state to it local adjacent network.
Note that a typical deployment at the ENNI Interconnection Zone would be
symmetrical between the two adjacent MENs/CENs while at the UNI one possible
deployment scenario is for the CE to have two Link Connections, each to a
different node supporting the UNI-N functionality (Dual Home configuration).
The requirement only defines the capability to support node failure when two or
more nodes protect a particular network in the Interconnection Zone, while the
actual deployment of this requirement is not mandated.
223
6.2
224
This section details the requirements addressing frame formats.
MEF xx
Requirements addressing Ethernet Layer
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 7
Requirements for Service Protection Across EIs – Phase 1
225
226
227
[R16] The protection switching mechanism MUST support ENNI Frames,
containing Service Frames encapsulated by S-Tags, as defined in the
ENNI specification [10].
228
229
230
231
232
233
234
235
[R17] The protection switching mechanism MUST NOT modify Ethernet frames
delivered by a Service End Point to the Link Connections in the
Interconnection Zone. These frames currently include Service Frames,
containing the payload and optionally C-Tags, or ENNI Frames,
containing Service Frames encapsulated by S-Tag.
Note that this requirement is designed to support the “preservation” Service Attributes. Note
also that this requirement does not preclude encapsulation inside the Interconnection Zone, as
long as the frames will enter the adjacent network unmodified.
236
237
238
239
240
241
242
[R18] The protection switching mechanism MUST ensure that Ethernet Frames
(unicast, multicast and broadcast frames) of a single Service End Point are
delivered once and only once to the adjacent network beyond the
Interconnection Zone.
Note that frames may not be delivered to the adjacent network during the protection
switching time.
243
6.3
244
6.3.1
245
246
247
248
249
250
251
252
253
254
Requirements addressing operator manual commands
[R19] The protection mechanism MUST support Operator manual commands to
switch Service End Points from Active Link Connection to Standby
Protection Link Connection in the Interconnection Zone.
6.4
255
256
257
258
259
260
261
262
263
Requirements addressing triggers for recovery actions
Requirements addressing configuration aspects
[R20] The protection switching mechanism MUST support the ability to
manually map Service End Points to specific Link Connections in the UNI
Interconnection Zone.
[R21] The protection switching mechanism MUST support the ability to
manually map Service End Points to specific Link Connections in the
ENNI Interconnection Zone.
Note that there is no requirement to map all End Points of the same service to a single Link
Connection. This decision is left to the discretion of the Operators. An example of multiple
End Points for a single service is the case of Hairpin.
264
265
[R22] The protection switching mechanism MUST support the ability to
configure a Service End Point as 'unprotected'.
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 8
Requirements for Service Protection Across EIs – Phase 1
266
267
268
269
Note that in this case when a failure occurs, the Service End Point will not participate in
protection switching. This requirement addresses cases where Service End Points are for
example, protected end-to-end by another mechanism and hence do not require local
protection at the Interconnection Zone.
270
271
272
273
[R23] The protection switching mechanism MUST support a Management
Entity's ability to retrieve the mapping configuration of Service End Points
to Link Connections during normal and failure conditions in the
Interconnection Zone.
274
275
276
[R24] The protection switching mechanism MUST support a Management
Entity's ability to retrieve the protection state, as defined in [R9], of each
Service End Point in the Interconnection Zone.
277
278
279
280
281
282
283
284
285
286
287
288
289
290
[R25] The protection switching mechanism MUST support the ability to operate
in a Non-Revertive Mode per Service End Point in the Interconnection
Zone.
This means that after the failure causing the protection switching is repaired, the protection
mechanism will not switch back the repaired Working Link Connection.
[D1]
This means that after the failure causing the protection switching is repaired, the protection
switching mechanism will switch back to the repaired Working Link Connection.
291
292
293
294
295
296
The protection switching mechanism SHOULD support the ability to
operate in a Revertive Mode per Service End Point in the Interconnection
Zone. The mechanism MUST have a configurable time to wait before
reverting back to the repaired Working Connection Link
[O1]
6.5
The protection mechanism MAY support both Service End Points that
operate in Revertive Mode together with other Service End Points that
operate in Non-Revertive Mode in the same Link Connection in the
Interconnection Zone.
Requirements for scalability and performance
297
298
[R26] The protection switching mechanism MUST support at least 4095
Services in the UNI Interconnection Zone.
299
300
[R27] The protection switching mechanism MUST support at least 4095
Services in the ENNI Interconnection Zone.
301
302
[R28] The protection switching mechanism MUST support at least 4095 Service
End Points in the UNI Interconnection Zone.
303
304
[R29] The protection switching mechanism MUST support at least 4095 Service
End Points in the ENNI Interconnection Zone.
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 9
Requirements for Service Protection Across EIs – Phase 1
305
306
307
[R30] The automatic and manual protection switching MUST perform the
protection switching in not more than 50 ms between Active and Standby
Link Connections in the Interconnection Zone.
308
309
310
311
312
[R31] The manual protection switching SHOULD be hitless (i.e., zero frame
loss).
313
314
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 10
Requirements for Service Protection Across EIs – Phase 1
315
7.
References
316
[1] RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels”, S. Bradner
317
318
[2] MEF Technical Specification MEF 2, “Requirements and Framework for Ethernet
Service Protection in Metro Ethernet Networks”
319
320
[3] MEF Technical Specification MEF 4, Metro Ethernet Network Architecture Framework
- Part 1: Generic Framework
321
[4] MEF Technical Specification MEF 6.1, “Ethernet Services Definitions - Phase 2”
322
[5] MEF Technical Specification, MEF 10.2, “Ethernet Services Attributes - Phase 2”
323
324
[6] MEF Technical Specification, MEF 11 “User Network Interface (UNI) Requirements
and Framework”
325
326
[7] MEF Technical Specification, MEF 13 “User Network Interface (UNI) Type 1
Implementation Agreement”
327
[8] MEF Technical Specification, MEF 17 “Service OAM Requirements & Framework”
328
329
[9] MEF Technical Specification, MEF 20, “User Network Interface (UNI) Type 2
Implementation Agreement”
330
[10] MEF Technical Specification, MEF 26, “Error! Reference source not found.”
331
[11] IEEE 802.1D-2004, “Part 3: Media Access Control (MAC) Bridges”
332
[12] IEEE 802.1Q – 2005, “Virtual Bridged Local Area Networks”
333
334
[13] IEEE 802.3-2008, “Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications”
335
336
337
[14] IEEE802.1AX -2008, "Standard for Local and Metropolitan Area Networks – Link
Aggregation"
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 11
Requirements for Service Protection Across EIs – Phase 1
338
339
340
8.
Appendix A – Several Operator Networks and their
Associated Interconnection Zones (Informative)
341
342
This Appendix provides an informative description of one model for protecting services
across several Interconnection Zones.
Interconnection
Zone
Interconnection
Zone
Interconnection
Zone
Interconnection
Zone
CE
CE
MEN/CEN
MEN/CEN
MEN/CEN
343
344
345
346
Figure 2 : Example of an EVC traversing several Operators' Networks and Interconnection
Zones
347
348
349
350
The figure illustrates various possible interconnection topologies between the Subscriber
premises and MENs/CENs as well as between the MENs/CENs themselves. The dashed lines
denote optional Link Connections. Note that the interconnection topologies shown in this
figure are just for illustration
351
itor Note
352 4: Editor's Note 9: { add more text ….}
353
354
355
356
357
MEF xx
© The Metro Ethernet Forum 2010. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Page 12