Technical Specification. Ethernet Services Attributes for Subscriber Services. 13 July 2017

Transcription

1 D00134_ Technical Specification Ethernet Services Attributes for Subscriber Services July 2017

2 16 Disclaimer D00134_ 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 MEF 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: a) 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 b) 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 c) 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 MEF 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 MEF Forum All Rights Reserved. 44

3 Table of Contents 1. List of Contributing Members Abstract Terminology and Acronyms Scope Compliance Levels Numerical Prefix Conventions Introduction Key Concepts and Definitions Ethernet Service Subscriber and Ethernet Service Provider Ethernet Service UNI, Subscriber Equipment, and Service Provider CEN Service Attributes Service Frames Types of Service Frame Layer 2 Control Protocol Service Frame SOAM Service Frame Data Service Frame Ethernet Service Ethernet Virtual Connection and EVC End Point Carrier Ethernet VLAN ID, Carrier Ethernet PCP, and Carrier Ethernet DEI Service Level Specification Ethernet Virtual Connection Service Attributes EVC ID Service Attribute EVC Type Service Attribute Point-to-Point EVC Multipoint EVCs Rooted-Multipoint EVC Multipoint-to-Multipoint EVC EVC EP List Service Attribute EVC Maximum Number of EVC EPs Service Attribute EVC Data Service Frame Disposition Service Attribute EVC CE-VLAN ID Preservation Service Attribute EVC CE-VLAN PCP Preservation Service Attribute EVC CE-VLAN DEI Preservation Service Attribute EVC List of Class of Service Names Service Attribute EVC Service Level Specification Service Attribute Key SLS Definitions, Concepts, and Notation Common Parameters Time Interval Sequences, Available Time, and Maintenance Interval Qualified Service Frames One-way Frame Delay One-way Frame Delay Performance Metric One-way Mean Frame Delay Performance Metric Page i

4 One-way Frame Delay Range Performance Metric One-way Inter-Frame Delay Variation Performance Metric One-way Frame Loss Ratio Performance for an EVC One-way Availability Performance Metric One-way High Loss Intervals Performance Metric One-way Consecutive High Loss Intervals Performance Metric One-way Composite Performance Metric One-way Group Availability Performance Metric EVC Group Membership Service Attribute EVC Maximum Service Frame Size Service Attribute EVC Available MEG Level Service Attribute Subscriber UNI Service Attributes Subscriber UNI ID Service Attribute Subscriber UNI Instantiation Service Attribute Subscriber UNI Virtual Frame Map Service Attribute Subscriber UNI List of Physical Links Service Attribute Subscriber UNI Link Aggregation Service Attribute Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute Subscriber UNI Service Frame Format Service Attribute Subscriber UNI Maximum Service Frame Size Service Attribute Subscriber UNI Maximum Number of EVC EPs Service Attribute Subscriber UNI Maximum Number of CE-VLAN IDs per EVC EP Service Attribute Subscriber UNI All to One Bundling Service Attribute Subscriber UNI Token Share Service Attribute Subscriber UNI Envelopes Service Attribute Subscriber UNI Ingress Bandwidth Profile Service Attribute Subscriber UNI Egress Bandwidth Profile Service Attribute Subscriber UNI Link OAM Service Attribute Subscriber UNI MEG Service Attribute Subscriber UNI L2CP Address Set Service Attribute Subscriber UNI L2CP Peering Service Attribute EVC EP Service Attributes EVC EP ID Service Attribute EVC EP UNI Service Attribute EVC EP Role Service Attribute EVC EP Map Service Attribute CE-VLAN ID Significance Describing the Value of the EVC EP Map Service Attribute EVC EP Ingress Class of Service Map Service Attribute EVC EP Ingress Class of Service Map Service Attribute for Data Service Frames EVC EP Ingress Class of Service Map Service Attribute Based on EVC EP EVC EP Ingress Class of Service Map Service Attribute Based on Priority Code Point Field EVC EP Ingress Class of Service Map Service Attribute Based on Internet Protocol EVC EP Ingress Class of Service Map Service Attribute for Layer 2 Control Protocol Service Frames Page ii

5 EVC EP Ingress Class of Service Map Service Attribute for SOAM Service Frames EVC EP Color Map Service Attribute EVC EP Color Map Service Attribute with F = EVC EP EVC EP Color Map Service Attribute with F = C-Tag DEI EVC EP Color Map Service Attribute with F = C-Tag PCP EVC EP Color Map Service Attribute with F = DSCP EVC EP Egress Map Service Attribute EVC EP Egress Map Form CNC-Tag PCP EVC EP Egress Map Form CCC-Tag DEI EVC EP Egress Map Form CCC-Tag PCP EVC EP Egress Map Service Attribute Requirements EVC EP Egress Equivalence Class Map Service Attribute EVC EP Egress Equivalence Class Map Service Attribute for Egress Data Service Frames Based on C-Tag Priority Code Point EVC EP Egress Equivalence Class Map Service Attribute for Egress Data Service Frames Based on Internet Protocol EVC EP Egress Equivalence Class Map Service Attribute for Egress L2CP Service Frames EVC EP Egress Equivalence Class Map Service Attribute for Egress SOAM Service Frames EVC EP Ingress Bandwidth Profile Service Attribute EVC EP Class of Service Name Ingress Bandwidth Profile Service Attribute EVC EP Egress Bandwidth Profile Service Attribute EVC EP Egress Equivalence Class Name Bandwidth Profile Service Attribute EVC EP Source MAC Address Limit Service Attribute EVC EP Test MEG Service Attribute EVC EP Subscriber MEG MIP Service Attribute Multiple EVC Service Level Specification Service Attribute Bandwidth Profile Bandwidth Profile Parameters Envelope Parameters Bandwidth Profile Flow Parameters Bandwidth Profile Algorithm Bandwidth Profile Algorithm With and Without Token Sharing Ethernet Service Framework References Appendix A Examples (Informative) A.1 EVC CE-VLAN ID Preservation Service Attribute A.1.1 EVC CE-VLAN ID Preservation Service Attribute Value = Enabled A.1.2 EVC CE-VLAN ID Preservation Service Attribute Value = Disabled A.2 Examples of the Use of the EVC EP Map and EVCs A.2.1 Untagged UNIs A.2.2 Use of Rooted-Multipoint EVC A.2.3 Redundant Higher Layer Service Access A.3 Examples of Availability Metrics for Multipoint EVCs Page iii

6 A.3.1 UNI-oriented Availability Example A.3.2 EVC-oriented Availability Example Appendix B Traffic Shaping Example (Informative) Appendix C Effect of Service Frame Overhead (Informative) Appendix D Bandwidth Profiles (Informative) D.1 Visual Representation of the Bandwidth Profile Token Flows D.2 Bandwidth Profile Use Cases D.2.1 Sharing Excess Bandwidth D.2.2 Uncoupled Bandwidth Sharing D.2.3 Sharing Bandwidth among Class of Service Names D.3 Examples of the Use of the Token Request Offset Parameter D.3.1 Adjusting for C-Tag Removal D.3.2 Adjusting for Inter-frame Gap, Preamble, and Frame Delimiter D.4 Bandwidth Profile Implementation D.4.1 Eliminating Bias Toward Short Service Frames Appendix E Example of the Use of the One-way Composite Performance Metric (Informative) 154 Appendix F UNI Physical Link Configuration Examples (Informative) Appendix G Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute Examples (Informative) G.1 Single EVC with Single Map Entry G.2 Single EVC with Multiple Map Entries G.3 Single EVC with the Subscriber UNI All to One Bundling Service Attribute = Enabled 159 G.4 Two EVCs with Multiple Map Entries G.5 Two EVCs with Multiple Class of Service Names and Single Bandwidth Profile Flow per Envelope G.6 Two EVCs with Multiple Class of Service Names and Multiple Bandwidth Profile Flows per Envelope Appendix H Changes from MEF 10.3 (Informative) H.1 Terminology Changes H.2 New Material H.3 Other Changes Revision History Scope Item Tracking Working Drafts History Page iv

7 List of Figures Figure 1 Fundamental Model Figure 2 IEEE Std Packet Format (Extension Field not shown) Figure 3 Point-to-Point EVCs Figure 4 Rooted-Multipoint EVC Example Figure 5 Multipoint-to-Multipoint EVC Figure 6 Tagged In to Tagged Out Data Service Frame Transparency Figure 7 Tagged In to Untagged Out Data Service Frame Transparency Figure 8 Untagged In to Tagged Out Data Service Frame Transparency Figure 9 Untagged In to Untagged Out Data Service Frame Transparency Figure 10 Example of a Value for PM Figure 11 Another Example of a Value for PM Figure 12 Flowchart Definition of Ai, j tk for a Given Class of Service Name Figure 13 Example of the Determination of Ai, j tk for a Given Class of Service Name Figure 14 Example of a Maintenance Interval Figure 15 One-way Frame Delay for Service Frame Figure 16 One-way Inter-Frame Delay Variation Definition Figure 17 Hierarchy of Time Showing the One-way Resiliency Attributes Figure 18 Determining and Counting Consecutive High Loss Intervals for a Given Class of Service Name Figure 19 Example of Counting Consecutive High Loss Intervals Figure 20 Flowchart Definition of ACTli, j tk Figure 21 Example of the Determination of ACTli, j tk Figure 22 Example of the Subscriber UNI Instantiation Service Attribute = Virtual Figure 23 Example of the Subscriber UNI Maximum Number of EVC EPs Service Attribute 72 Figure 24 Example of a Simple Description of the EVC EP Map Service Attribute Value Figure 25 Subscriber UNI Ingress Bandwidth Profile Example Figure 26 Subscriber UNI Egress Bandwidth Profile Example Figure 27 Examples of the Value of the EVC EP Map Service Attribute Figure 28 Example of the value of the UNI Subscriber Maximum Number of CE-VLAN IDs per EVC EP Service Attribute Figure 29 Examples of Valid EVC EP Map Service Attribute Values Figure 30 EVC EP Ingress Bandwidth Profile Service Attribute Example Figure 31 EVC EP Class of Service Name Ingress Bandwidth Profile Service Attribute Example Figure 32 Frame Discard for Source MAC Address Limit Figure 33 Example of the Multiple EVC SLS Service Attribute Figure 34 Example of the Calculation of ATl tk Figure 35 The Bandwidth Profile Algorithm Figure 36 Example 1: Subscriber UNI All to One Bundling Service Attribute Value = Enabled Figure 37 Example 2: Subscriber UNI Maximum Number of CE-VLAN IDs per EVC EP Service Attribute Value Figure 38 Example 3: EVC CE-VLAN ID Preservation Service Attribute Value = Disabled 128 Figure 39 Example 4: EVC CE-VLAN ID Preservation Service Attribute Value = Disabled 129 Page v

8 Figure 40 Example 5: EVC CE-VLAN ID Preservation Service Attribute Value = Disabled 129 Figure 41 Example 6: EVC CE-VLAN ID Preservation Service Attribute Value = Disabled 129 Figure 42 Untagged UNIs Figure 43 Use of a Rooted-Multipoint EVC Figure 44 Redundant Higher Layer Service Access Figure 45 Multipoint EVC Example Figure 46 Periodic Algorithm Figure 47 New Frame Algorithm Figure 48 IEEE Std Packet Format (simplified) Figure 49 Ratio of Information Rate to UNI Line Rate for Back to Back Service Frames Figure 50 Bandwidth Profile Token Flows Figure 51 Bandwidth Profile Algorithm for Sharing Excess Bandwidth Figure 52 Bandwidth Profile Algorithm for Uncoupled Bandwidth Sharing Figure 53 Bandwidth Profile Algorithm for Bandwidth Sharing among Class of Service Names Figure 54 Use of the Token Request Offset Parameter for Tagged to Untagged Service Frames Figure 55 Use of the Token Request Offset Parameter to Adjust for Ethernet Frame Overhead Figure 56 Service Frame Profiling Results for the Algorithm of Section Figure 57 Service Frame Profiling Results for Modified Algorithm (Time Measured Last Bit to Last Bit) Figure 58 Service Frame Profiling Results for Modified Algorithm (Time Measured First Bit to First Bit) Figure 59 Mobile Backhaul Base Station Synchronization Over an EVC Figure 60 Single Device in Both the SE and the Service Provider CEN Figure 61 Single Device in the SE and Two Devices in the Service Provider CEN Figure 62 Two Devices in the SE and Two Devices in the Service Provider CEN Figure 63 Single EVC with a Single Port Conversation ID to Aggregation Link Map Entry. 158 Figure 64 Two EVCs Multiplexed at UNI-A Page vi

9 List of Tables Table 1 Terminology and Acronyms Table 2 Numerical Prefix Conventions Table 3 List of Standardized Layer 2 Control Protocol Destination MAC Addresses Table 4 CE-VLAN ID Value for Service Frames Table 5 Required CE-VLAN ID Preservation Behavior Table 6 Example value for the EVC List of Class of Service Names Service Attribute Table 7 PM Entry for the One-way Frame Delay Performance Metric Table 8 PM Entry for the One-way Mean Frame Delay Performance Metric Table 9 PM Entry for the One-way Frame Delay Range Performance Metric Table 10 PM Entry for the One-way Inter-Frame Delay Variation Performance Metric Table 11 PM Entry for the One-way Frame Loss Ratio Performance Metric Table 12 PM Entry for the One-way Availability Performance Metric Table 13 PM Entry for the One-way High Loss Intervals Performance Metric Table 14 PM Entry for the One-way Consecutive High Loss Intervals Performance Metric.. 54 Table 15 PM Entry for the One-way Composite Performance Metric Table 16 PM Entry for the One-way Group Availability Performance Metric Table 17 Allowed Values of the Subscriber UNI Link Aggregation Service Attribute Table 18 Example of a Value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute for a UNI Table 19 Envelope Parameters Table 20 Examples of Mapping PCP Value to Class of Service Name Table 21 Example of M when F Equals DSCP Table 22 Example of M that Only Supports IPv4 when F Equals DSCP Table 23 Example of DSCP to Color Mapping Table 24 Example of the EVC EP Egress Map Service Attribute Form CNC-Tag PCP Table 25 Example of the EVC EP Egress Map Service Attribute Form CCC-Tag DEI Table 26 Example of the EVC EP Egress Map Service Attribute Form CCC-Tag PCP Table 27 EVC EP Map Form Usage for an EVC EP at a UNI and the Egress Service Frame Has a C-Tag Table 28 Examples of Mapping PCP Value to Egress Equivalence Class Name Table 29 Example of M when F equals DSCP Table 30 Example of M that Only Supports IPv4 when F Equals DSCP Table 31 Allowed Combinations of Ingress Bandwidth Profile Service Attributes Values for a Given EVC EP Table 32 Allowed Combinations of Egress Bandwidth Profile Service Attributes Values for a Given EVC EP Table 33 Envelope Parameters Table 34 Bandwidth Profile Flow Parameters Table 35 Required Lower Bounds on CBS and EBS Table 36 Values of MEF 41 General Parameters Table 37 Values of MEF 41 TRF Parameters for Rank i, i = 1, 2, n Table 38 Values for Token Requests for Bandwidth Profile Flow with Rank i, i = 1, 2, n 118 Table 39 Subscriber UNI Service Attributes Page vii

10 Table 40 EVC Service Attributes Table 41 EVC EP Service Attributes Table 42 Alternative Approach to Untagged UNIs Table 43 Parameter Values for Sharing Bandwidth among Class of Service Names Table 44 Service Frame Profiling Results for the Last 250 Service Frames Table 45 PM Entry for the One-way Composite Performance Metric for Packet Synchronization Table 46 Both VLAN IDs in One Row of the Port Conversation to Link Aggregation Map. 158 Table 47 VLAN IDs in Different Row of the Port Conversation to Link Aggregation Map Table 48 All VLAN IDs in One Row of the Port Conversation to Link Aggregation Map Table 49 VLAN IDs Spread Across Two Rows of the Port Conversation to Link Aggregation Map Table 50 Different VLAN IDs Have Different Resiliency Table 51 Link Shared by Two EVCs Table 52 EVC Configurations Table 53 Each Single Bandwidth Flow Envelope Carried on a Single Link Table 54 Multiple Bandwidth Profile Flow Envelope on a Single Link Table 55 Terminology Changes from MEF Page viii

11 List of Contributing Members The following members of the MEF Forum participated in the development of this document and have requested to be included in this list. Editor Note 1: Even though the following member names reflect brilliant marketing, they are fictitious. The list will be populated with valid MEF Forum member names before publication. AAA Ethernet Services & Plumbing Static Agility, Inc. Glorious Ultimate Solution Systems ZZZ Sleep Placeholder Systems Page 1

12 Abstract The attributes of Ethernet Services observable at a Ethernet Service User Network Interface and from Ethernet Service User Network Interface to Ethernet Service User Network Interface are defined. In addition, a framework for defining specific instances of Ethernet Services is described. This document supersedes and replaces MEF 10.3 [18], MEF [19], and MEF [20]. Page 2

13 Terminology and Acronyms Editor Note 2: The table needs to be put in ascending alphabetical order by term before final CFCB Term Definition Source Available Time Bandwidth Profile Bandwidth Profile Flow Broadcast Data Service Frame Bundling The intervals, during some longer time period, when the service is considered available for use. A characterization of the lengths and arrival times for Service Frames at a UNI. A Data Service Frame that has the broadcast Destination MAC Address. (1) The condition when there is more than one CE- VLAN ID value mapped to an EVC EP at a UNI. (2) The capability of the Service Provider CEN to map more than one CE-VLAN ID value to an EVC EP. docu- This ment docu- This ment This section defines the terms used in this document. In many cases, the normative definitions to terms are found in other documents. In these cases, the third column is used to provide the reference that is controlling, in other MEF Forum or external documents. docu- This ment A set of Service Frames at a UNI that meet specific criteria. docu- This ment Carrier Ethernet Network Carrier Ethernet VLAN DEI Carrier Ethernet VLAN ID Carrier Ethernet VLAN PCP Carrier Ethernet VLAN Tag A network from a Service Provider or network Operator MEF 12.2 supporting the MEF service and architecture models. 1 [21] The Carrier Ethernet VLAN DEI (CE-VLAN DEI) is defined as the DEI filed of a C-Tagged Service Frame. The identifier derivable from the content of a Service Frame that allows the Service Frame to be mapped to an EVC EP at the UNI. The Carrier Ethernet VLAN PCP (CE-VLAN PCP) is defined as the PCP field of a C-Tagged Service Frame. The IEEE Std 802.1Q 2014 Customer VLAN Tag in a C-Tagged Service Frame. docu- This ment docu- This ment docu- This ment docu- This ment docu- This ment CEN Carrier Ethernet Network. MEF 12.2 [21] 1 This document addresses MEF services only from a Service Provider. Page 3

14 Term Definition Source CE-VLAN DEI Carrier Ethernet VLAN DEI This document CE-VLAN ID Carrier Ethernet VLAN ID. This document CE-VLAN PCP Carrier Ethernet VLAN PCP This document CE-VLAN Tag Carrier Ethernet VLAN Tag. This document CF Coupling Flag. This document CHLI Consecutive High Loss Interval. This document Class of Service Name Consecutive High Loss Interval A designation given to one or more sets of Performance Metric Objectives and associated parameters by the Service Provider. A sequence of small time intervals contained in T, each with a high frame loss ratio. MEF 23.2 [25] This document CoS Class of Service. This document Data Service Frame A Service Frame that is neither a Layer 2 Control Protocol Service Frame nor a SOAM Service Frame. docu- This ment DEI Drop Eligible Indicator. IEEE Std 802.1Q 2014 [3] DSCP Differentiated Services Code Point. RFC 2474 [11] DTE Data Termination Equipment. IEEE Std [4] Egress Equivalence Class Name Bandwidth Profile Flow Egress EVC EP Bandwidth Profile Flow All egress Service Frames at a UNI that have a given Egress Equivalence Class Name and that map to a given EVC EP. All egress Service Frames at a UNI that are mapped to a given EVC EP. docu- This ment docu- This ment Page 4

15 Term Definition Source Egress Service Frame Egress UNI Bandwidth Profile Flow Envelope A Service Frame transmitted across the UNI toward the Subscriber.. docu- This ment All egress Service Frames at a UNI. This document A set that contains an integer n 1 number of Bandwidth Profile Flows that can share bandwidth resources that are represented by tokens. docu- This ment EP End Point This document Ethernet Service Ethernet Service Provider Ethernet Service Subscriber docu- This ment A connectivity service that carries Ethernet Frames irrespective of the underlying technology, that is specified using Service Attributes as defined in an MEF Specification. The organization providing Ethernet Service(s). This document The demarcation point between the responsibility of the Service Provider and the responsibility of the Subscriber for an Ethernet Service. docu- This ment docu- This ment The organization purchasing and/or using Ethernet Services. Ethernet Service User Network Interface ESMC Ethernet Synchronization Message Channel. ITU G.8264 [6] Ethernet Virtual Connection An association of EVC EPs. This document EVC Ethernet Virtual Connection. This document EVC End Point A construct at a UNI that selects a subset of the Service Frames that pass over the UNI. docu- This ment EVC EP EVC End Point This document Frame Short for Ethernet frame or Service Frame This document High Loss Interval A small time interval contained in T l with a high frame loss ratio. This document Page 5

16 Term Definition Source HLI High Loss Interval. This document Information Rate Ingress Class of Service Name Bandwidth Profile Flow Ingress EVC EP Bandwidth Profile Flow Ingress Service Frame Ingress UNI Bandwidth Profile Flow Inter-Frame Delay Variation L2CP Service Frame The average bit rate of Ethernet service frames at the measurement point starting with the first MAC address bit and ending with the last FCS bit. All ingress Service Frames at a UNI that have a given Class of Service Name, that are mapped to a given EVC EP, and that are not discarded per [R77] with the possible exception of Service Frames discarded per [R112], [D1], [D2], [D7], or any of the conditions specified per [R16]. All ingress Service Frames at a UNI that are mapped to a given EVC EP and that are not discarded per [R77] with the possible exception of Service Frames discarded per [R112], [D1], [D2], [D7], or any of the conditions specified per [R16]. A Service Frame transmitted across the UNI toward the Service Provider. All ingress Service Frames at a UNI that are not discarded per [R77] with the possible exception of Service Frames discarded per [R112], [D1], [D2], [D7], or any of the conditions specified per [R16]. The difference between the one-way delays of a pair of selected Service Frames. ITU Y.1564 [9] docu- This ment docu- This ment docu- This ment IFDV Inter-Frame Delay Variation. This document docu- This ment docu- This ment Layer 2 Control Protocol Service Frame. This document LAG Link Aggregation Group. IEEE Std 802.1AX 2014 [2] Layer 2 Control Protocol Service Frame A Service Frame that could be used in a recognized Layer 2 Control Protocol. docu- This ment Leaf EVC EP An EVC EP that has the role of Leaf. This document Page 6

17 Term Definition Source Link Number ID Link Selection Priority List Maintenance Interval Multicast Data Service Frame Multipoint EVC This ment Multipoint-to- Multipoint EVC One-way Frame Delay An integer 1 that is uniquely assigned to each physical link at a given UNI when the value of the Subscriber UNI Instantiation Service Attribute = Physical. A field in the Port Conversation ID to Aggregation Link Map that consists of a sequence of Link Number IDs that indicates the order of link usage for a Port Conversat1on ID when the value of the Subscriber UNI Instantiation Service Attribute = Physical. A time interval agreed upon by both the Subscriber and Service Provider during which the service may not perform well or at all. A Data Service Frame that has a multicast Destination MAC Address. An EVC whose value of the EVC Type Service Attribute = Multipoint-to-Multipoint. An EVC associating two or more EVC EPs with all EVC EPs having the Root Role. A Multipoint-to-Multipoint EVC associating two EVC EPs is different from a Pointto-Point EVC because one or more additional EVC EPs can be added to it. The time elapsed from the reception of the first bit of the ingress Service Frame at UNI 1 until the transmission of the last bit of the first corresponding egress Service Frame at UNI 2 Adapted from IEEE Std AX 2014 [2] Adapted from IEEE Std AX 2014 [2] docu- docu- This ment docu- This ment docu- This ment docu- This ment PCP Priority Code Point. IEEE Std 802.1Q 2014 [3] Performance Metric Objective Point-to-Point EVC Port Conversation ID A quantitative characterization of Service Frame delivery quality experienced by the Subscriber. A value associated with a Performance Metric that reflects the promised Service Frame delivery quality. An EVC whose value of the EVC Type Service Attribute = Point-to-Point. An identifier for a set of Service Frames that are selected to pass over a physical link at a given UNI when the value of the Subscriber UNI Instantiation Service Attribute = Physical. docu- This ment docu- This ment Performance Metric docu- This ment Adapted from IEEE Std AX 2014 [2] Page 7

18 Term Definition Source Priority Tagged Service Frame A Service Frame with a TPID = 0x8100 following the Source Address and the corresponding VLAN ID value is 0x000 in the tag following the TPID. Qualified Service Frames The set of frames that comply with specific criteria, such as the arrival time at the Ingress UNI and Bandwidth Profile compliance, on which a performance attribute is based. docu- This ment docu- This ment Rooted-Multipoint EVC An EVC whose value of the EVC Type Service Attribute = Rooted-Multipoint. docu- This ment Root EVC EP An EVC EP that has the role of Root. This document SE Subscriber Equipment This document Service Frame Service Level Agreement Service Level Specification When the value of the Subscriber UNI Instantiation Service Attribute = Physical, the Service Frame for the UNI is defined as the first bit of the Destination Address through the last bit of the Frame Check Sequence of the IEEE Std Ethernet frame that passes over a an IEEE Std Physical Layer. When the value of the Subscriber UNI Instantiation Service Attribute = Virtual, the Service Frame is defined as the first bit of the Destination Address through the last bit of the Frame Check Sequence of the IEEE Std Ethernet frame that results from applying the value of the Subscriber UNI Virtual Frame Map Service Attribute to the Virtual Frame." The contract between the Subscriber and Service Provider specifying the service level commitments and related business agreements. The technical specification of the service level being offered by the Service Provider to the Subscriber. (1) The condition when there is more than one EVC End Point located at a UNI. (2) The capability of the Service Provider CEN to locate more than one EVC End Point at a UNI. docu- This ment docu- This ment docu- This ment docu- This ment Service Multiplexing Service Provider Short for Ethernet Service Provider. This document Page 8

19 Term Definition Source SES Severely Errored Seconds. ITU Y.1563 [8] SLA Service Level Agreement. This document SOAM Service Operations Administration and Maintenance MEF 30.1 [28] SOAM Service Frame A Service Frame whose MAC Destination Address does not indicate it to be an L2CP Service Frame and whose Ethertype = 0x8902. docu- This ment SLS Service Level Specification. This document Subscriber Short for Ethernet Service Subscriber. This document Subscriber Equipment t s T Tagged Service Frame Equipment on the Subscriber side of the UNI. A time that represents the date and time for the start of the SLS. A time interval that is used in conjunction with t s to specify time intervals for determining when Performance Metric Objectives are met. A Service Frame that is either a VLAN Tagged Service Frame or a Priority Tagged Service Frame. This document This document TPID Tag Protocol Identifier. IEEE Std 802.1Q 2014 [3] Unavailable Time The intervals, during some longer time period, when the service is considered not available for use. docu- This ment This document docu- This ment UNI Ethernet Service User Network Interface. This document UNI-C UNI-N A compound architectural component of the SE that represents all of the functions required to connect a SE to the CEN. The UNI-N is a compound architectural component of the CEN that represents all of the functions required to connect the CEN to the SE. Adapted from MEF 4 [14] Adapted from MEF 4 [14] Page 9

20 Term Definition Source UNI Line Rate Unicast Data Service Frame Untagged Service Frame Utilized Line Rate Virtual Frame VLAN Tagged Service Frame When the value of the Subscriber UNI Instantiation Service Attribute = Physical, the MAC data rate 2 at the UNI. A Data Service Frame that has a unicast Destination MAC Address. A Service Frame with the two bytes following the Source Address field containing neither the value 0x8100 nor the value 0x88a8. The average bit rate of the Ethernet line at the measurement point, including the bits a) allocable to the minimum-duration period of each Inter-Packet gap (but not the number of bits allocable to the part of each Inter- Packet gap longer than the minimum), b) in the preamble, c) in the start of frame delimiter and d) in the Ethernet Service Frame starting with the first MAC address bit and ending with the last FCS bit. A Service Frame with a TPID = 0x8100 following the Source Address and the corresponding VLAN ID value is not 0x000 in the tag following the TPID. docu- This ment docu- This ment docu- This ment ITU Y.1564 [9] docu- This ment The information passed across the UNI when the value of the Subscriber UNI Instantiation Service Attribute = Virtual. docu- This ment 381 Table 1 Terminology and Acronyms See IEEE [4] for the definition of MAC data rate. Page 10

21 Scope This document describes Ethernet Service attributes for services provided to the Ethernet Service Subscriber by the Ethernet Service Provider. The Ethernet Services are modeled from the point of view of the Subscriber s equipment referred to as the Subscriber Equipment (SE) that is used to access the service. The basic elements of Ethernet Services are defined. In addition, a number of Service Attributes are defined that may be offered as part of an Ethernet Service including the definition of Service Level Specification. This document supersedes and replaces MEF 10.3, Ethernet Services Attributes Phase 3 [18], MEF , Composite Performance Metric (CPM) Amendment to MEF 10.3 [19], and MEF , Amendment to MEF UNI Resiliency Enhancement [20]. The goals of this Technical Specification are two-fold. The first goal is to provide sufficient technical specificity to allow an Ethernet Subscriber to successfully plan and integrate Ethernet Services into his or her overall networking infrastructure. The second goal is to provide enough detail that Subscriber Equipment vendors can implement capabilities into their products so that they can be used to successfully access Ethernet Services. It follows as a corollary that vendors of Ethernet Service Provider network equipment will make use of this information for implementing functions that complement the functions in the SE. The differences between this document and MEF 10.3 [18] are described in Appendix H. Page 11

22 Compliance Levels The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [10]. All key words must be in upper case, bold text. Items that are REQUIRED (contain the words MUST or MUST NOT) are labeled as [Rx] for required. Items that are RECOMMENDED (contain the words SHOULD or SHOULD NOT) are labeled as [Dx] for desirable. Items that are OPTIONAL (contain the words MAY or OP- TIONAL) are labeled as [Ox] for optional. Page 12

23 Numerical Prefix Conventions This document uses the prefix notation to indicate multiplier values as shown in Table 2. Decimal Binary Symbol Value Symbol Value k 10 3 Ki 2 10 M 10 6 Mi 2 20 G 10 9 Gi 2 30 T Ti 2 40 P Pi 2 50 E Ei 2 60 Z Zi 2 70 Y Yi 2 80 Table 2 Numerical Prefix Conventions Page 13

24 Introduction The model for Ethernet Services is described as follows: Key concepts and definitions are detailed in Section Service Attributes for the Ethernet Virtual Connection (Section 8.7) are described in Section 9. Service Attributes for the Ethernet Service UNI (Section 8.2) are described in Section 10. Service Attributes for the EVC End Point (Section 8.7) are described in Section 11. Performance Service Attributes that apply to multiple EVCs are described in Section 12. The details of the Bandwidth Profile parameters and algorithm are described in Section 13. Extensive examples and supplementary explanations are contained in Appendix A through Appendix G. Appendix H summarizes the changes in going from MEF 10.3 [18] to this document. Page 14

25 Key Concepts and Definitions 437 Editor Note 3: This section is added per the discussion on the 5/10/2017 call This section introduces concepts and definition that are used throughout this document. 8.1 Ethernet Service Subscriber and Ethernet Service Provider This document deals with two organizations, the Ethernet Service Subscriber and the Ethernet Service Provider. The Ethernet Service Subscriber is the buyer of services and the Ethernet Service Provider is the seller of the services. In the interest of brevity, the remainder of this document uses Service Provider as short for Ethernet Service Provider and Subscriber as short for Ethernet Service Subscriber. 8.2 Ethernet Service UNI, Subscriber Equipment, and Service Provider CEN Editor Note 4: During the 5/10/2017 call it was agreed to include the UNI-C and UNI-N definitions in this sub-section. However, it seems sufficient to just include them in the terminology table because UNI-C and UNI-N are not fundamental to describing Ethernet Service. See the terminology table The model underlying this document consists of three components as shown in Figure 1. The Ethernet Service User Network Interface is the demarcation point between the responsibility of the Service Provider and the responsibility of the Subscriber. Throughout this document, UNI refers to the Ethernet Service User Network Interface. The Subscriber Equipment (SE) is defined as all equipment on the Subscriber side of the UNI. There are no assumptions about the details of the SE. The Ethernet Service Provider Carrier Ethernet Network (CEN) is defined as all equipment on the Service Provider side of the UNIs. There are no assumptions about the details of the CEN. It could consist of a single switch or an agglomeration of networks based on many different technologies. For an architectural perspective of the Carrier Ethernet Network see MEF [21]. 460 Page 15

26 Ethernet Service User Network Interface (UNI) Ethernet Service User Network Interface (UNI) Subscriber Equipment (SE) Ethernet Service Provider Carrier Ethernet Network (CEN) Figure 1 Fundamental Model Subscriber Equipment (SE) 463 This document is based on the two following requirements [R1] [R2] A UNI MUST be dedicated to a single Subscriber. Services provided at a UNI MUST be provided by a single Service Provider Although this document is focused on Ethernet Service (Section 8.6), [R2] does not preclude the Service Provider from offering other kinds of service at the UNI. 8.3 Service Attributes MEF Services are specified using Service Attributes. A Service Attribute captures specific information that is agreed between the Service Provider and the Subscriber, that describes some aspect of the service behavior. How such an agreement is reached is not specified by MEF and is outside the scope of this document. How the agreement is reached, and the specific values agreed, may have an impact on the price of the service or on other business or commercial aspects of the relationship between the Subscriber and the Service Provider; this is not specified by MEF and is outside the scope of this document. Some examples are given below, but this is not an exhaustive list The Service Provider mandates a particular value. The Subscriber selects from a set of options specified by the Service Provider. The Subscriber requests a particular value, and the Service Provider indicates accepts or rejects the value. Page 16

27 Frame Packet 481 The Subscriber and Service Provider negotiate to reach a mutually acceptable value Service Attributes describe the externally visible behaviors at a UNI and between UNIs; they do not constrain how the service is implemented in the CEN, or how the Subscriber implements the SE Editor Note 5: Discussions during the conference calls generated consensus that a Service Attribute like the Subscriber UNI Maximum Number of EVC EPs Service Attribute is useful and represents a capability. The following text is meant to describe the difference between a current behavior and a capability A Service Attribute can describe existing behavior or a capability. An example of an existing behavior is the physical layer(s) in use at the UNI which is specified by the value of the Subscriber UNI Physical Layer Service Attribute (Section 10.4). An example of a capability is the maximum number of Ethernet Services that can be accessed at the UNI (as opposed to the number Ethernet Services currently be accessed) as specified by the value of the Subscriber UNI Maximum Number of EVC EPs Service Attribute (Section 10.9). 8.4 Service Frames The SE and CEN exchange Service Frames across the UNI. A Service Frame transmitted across the UNI toward the Service Provider is called an ingress Service Frame. A Service Frame transmitted across the UNI toward the Subscriber is called an egress Service Frame. Service Frames are exchanged via an IEEE Std [4] Physical Layer or by other means from which an IEEE Std [4] Ethernet frame can be inferred. The definition of Service Frame is presented in Section 0. The Service Frame is defined as the IEEE Std Frame as shown in Figure 2. It consists of the first bit of the Destination MAC Address through the last bit of the Frame Check Sequence. The allowed formats for the Service Frame are detailed in Section Throughout this document: 12 bytes Inter-Packet Gap 7 bytes Preamble 1 byte Start Frame Delimiter 6 bytes Destination Address 6 bytes Source Address 2 bytes Length/Type Variable Length MAC Client Data & Pad 4 bytes Frame Check Sequence Figure 2 IEEE Std Packet Format (Extension Field not shown) Page 17

28 When the field following the Source Address field is a TPID 3 with the value 0x8100 and the corresponding VLAN ID value is not 0x000, the Service Frame is said to be a VLAN Tagged Service Frame. When the field following the Source Address field is a TPID 3 with the value 0x8100 and the corresponding VLAN ID value is 0x000, the Service Frame is said to be a Priority Tagged Service Frame. A Service Frame that is either a VLAN Tagged Service Frame or a Priority Tagged Service Frame is said to be a C-Tagged Service Frame. When the field following the Source Address field is a TPID 3 with the value 0x88a8, the Service Frame is said to be an S-Tagged Service Frame. When the two bytes following the Source Address field of the Service Frame do not contain the value 0x8100 or the value 0x88a8, the Service Frame is said to be an Untagged Service Frame Note that the definition of Untagged Service Frame means that a Service Frame with the two bytes following the Source Address field containing 0x88e7 (a Backbone Service Instance Tag per IEEE Std 802.1Q 2014 [3]) is an Untagged Service Frame. Also note that the behavior for S-Tagged Service Frames is beyond the scope of this document and the term "S-Tagged Service Frame" does not appear in the remainder of this document. Consequently, the behavior experienced by S-Tagged Service Frames can vary from Service Provider to Service Provider. A Subscriber who wants to use S-Tagged Service Frames is urged to check with the Service Provider to determine the behavior for such Service Frames. 8.5 Types of Service Frame There are three types of Service Frame as detailed in Sections 8.5.1, 8.5.2, and Layer 2 Control Protocol Service Frame A Layer 2 Control Protocol Service Frame (L2CP Service Frame) is a Service Frame that could be used in a recognized Layer 2 Control Protocol. Given that there are several Layer 2 protocols used for various control purposes, it is important that Carrier Ethernet Networks be able to process such information effectively [R3] A Service Frame whose destination MAC address is one of the addresses listed in Table 3 MUST be treated as a Layer 2 Control Protocol Service Frame Some Layer 2 Control protocols share the same destination MAC address and are identified by additional fields such as the Ethertype. Therefore, disposition of Service Frames carrying Layer 3 TPID, Tag Protocol Identifier, is defined in IEEE Std 802.1Q 2014 [3]. 4 This capability will be especially important for Subscribers who choose to deploy IEEE Std 802.1Q 2014 [3] bridges (as opposed to routers) at UNIs. Page 18

29 Control Protocols can be different for different protocols that use the same destination MAC address. MAC Destination Addresses 5 Description C through C F Bridge Block of protocols C through C F MRP Block of protocols Table 3 List of Standardized Layer 2 Control Protocol Destination MAC Addresses [O1] A Service Provider and Subscriber MAY agree to define additional fields and/or field values for identifying Layer 2 Control Protocol Service Frames in addition to those in Table Note that [O1] allows the use of proprietary protocols to specify Layer 2 Control Protocol Service Frames. Sections and describe how L2CP Service Frames carrying standardized Layer 2 Control Protocols can be handled by the CEN. In addition, the Subscriber and Service Provider are free to agree on how proprietary multicast Layer 2 Control Protocols are handled. Such agreements are beyond the scope of this document. Note that proprietary Layer 2 Control Protocols not identified via agreement per [O1] could be treated as Data Service Frames (Section 8.5.3) with special delivery behavior per the value of the EVC Service Frame Delivery Service Attribute (Section 9.5) SOAM Service Frame A Service Frame, with or without a C-Tag, whose MAC Destination Address does not indicate the frame to be an L2CP Service Frame and whose Ethertype = 0x8902 is defined to be a SOAM Service Frame. (See Table 21-1 of IEEE Std 802.1Q 2014 [3].) Sections 10.17, 11.14, and contain requirements for the handling of certain SOAM Service Frames. Other requirements for handling SOAM Service Frames can be found in MEF 17 [22], MEF 30.1 [28], MEF [29], and MEF 35.1 [32] Data Service Frame A Data Service Frame is defined as a Service Frame that meets one of the following three conditions: 1. It is not a Layer 2 Control Protocol Service Frame and not a SOAM Service Frame, 2. It is an ingress Layer 2 Control Protocol Service Frame whose proper handling requires it to be passed at the ingress and egress UNIs per the requirements in MEF 45 [38], or 5 Hexadecimal canonical format Page 19

30 It is an ingress SOAM Service Frame at or above the value of the EVC Available MEG Level Service Attribute (Section 9.13) and of a type that is passed transparently by any Subscriber MEG MIP. Note that a Layer 2 Control Protocol Service is also a Data Service Frame if condition 2 is met and a SOAM Service Frame is also be a Data Service Frame if condition 3 A Data Service Frame with a unicast Destination MAC Address is defined to be a Unicast Data Service Frame. 6 A Data Service Frame with a multicast Destination MAC Address is defined to be a Multicast Data Service Frame. 6 A Data Service Frame with a broadcast Destination MAC Address is defined to be a Broadcast Data Service Frame Ethernet Service Ethernet Service is a connectivity service that carries Ethernet Frames irrespective of the underlying technology, that is specified using Service Attributes as defined in an MEF Specification. In this document, Service Frames are carried by the CEN. An ingress Service Frame at UNI A is said to be delivered to UNI B when the ingress Service Frame at UNI A results in an egress Service Frame at UNI B with Destination Address through MAC Client Data & Pad unchanged. 8.7 Ethernet Virtual Connection and EVC End Point A fundamental aspect of Ethernet Services is the Ethernet Virtual Connection (EVC). An EVC is an association of two or more EVC End Points (EPs). An EVC EP is a construct at a UNI that selects a subset of the Service Frames that pass over the UNI. The subset of Service Frames is specified via the EVC EP Map Service Attribute as described in Section An EVC EP represents the logical attachment of an EVC to a UNI. The EVC EPs associated by an EVC are said to be in the EVC. A given UNI can support more than one EVC EP. An ingress Service Frame that is mapped to an EVC EP associated by an EVC (see Section 11.4) can be delivered to zero or more UNIs that have EVC EPs in that EVC; and only to UNIs other than the ingress UNI. For ease of discourse, frame is delivered to an EVC EP means frame is an egress Service Frame at the UNI where the EVC EP is located. And UNIs that are in the EVC means the set of UNIs such that each UNI has an EVC EP that attaches the UNI to the EVC [R4] [R5] If an egress Service Frame mapped to an EVC EP results from an ingress Service Frame mapped to an EVC EP, there MUST be an EVC that associates the two EVC EPs. If an egress Service Frame mapped to an EVC EP results from an ingress Service Frame mapped to an EVC EP, the two EVC EPs MUST be different from each other. 6 See Section 10.7 for details about the format of the Service Frame. Page 20

31 An EVC always supports bi-directional transmission of Service Frames. That is, each EVC EP associated by the EVC always supports ingress and egress Service Frames for that EVC. Note that ingress Service Frames can originate at any EVC EP in the EVC. In the context of this document, an Ethernet Service consists of a single EVC, associated UNIs and EVC EPs, that is provided to a Subscriber by a Service Provider. 8.8 Carrier Ethernet VLAN ID, Carrier Ethernet PCP, and Carrier Ethernet DEI Editor Note 6: During CFCB1 there was discussion about making the range of values [0,1,2,,4094]. One implication of this would be that an ingress Service Frame with C-Tag VLAN ID = 4095 would always be discarded. This behavior would not be consistent with EPL, EPLAN, etc. as defined in MEF 6.2. It was also thought that this behavior would break a Provider Bridges CEN implementation with just an S-component as the Service Provider edge bridge Each Service Frame contains a Carrier Ethernet VLAN ID (CE-VLAN ID) value that is an integer in the range [0,1,2,,4095]. Table 4 defines the value of the CE-VLAN ID value for Service Frames. Note that the CE- VLAN ID value is the same for Priority Tagged Service Frames and Untagged Service Frames. Service Frame Format CE-VLAN ID Value VLAN Tagged Service Frame VLAN ID value in the C-Tag Priority Tagged Service Frame 0 Untagged Service Frame 0 Table 4 CE-VLAN ID Value for Service Frames At a UNI, a given CE-VLAN ID value can map to an EVC EP (Section 8.7) via the EVC EP Map Service Attribute (Section 11.4). 626 [O2] An ingress Service Frame with CE-VLAN ID = 4095 MAY be discarded Note that [O2] applies irrespective of the value of the Subscriber UNI All to One Bundling Service Attribute (Section 10.11). Note that the Customer VLAN Tag values 0 and 4095 in IEEE Std 802.1Q 2014 [3] are reserved for special purposes and thus the number of VLANs in a Subscriber network is typically less than Nevertheless, Tagged Service Frames with any VLAN ID value as well as Untagged Service Frames can exist at the UNI. Consequently there are 4096 CE-VLAN ID values. However, fewer than 4096 EVCs can be supported at a UNI. See Section All 4096 CE-VLAN ID values are always defined at a UNI irrespective of which ones are contained in a value of an EVC EP Map Service Attribute (Section 11.4). A CE-VLAN ID value that does not map to an EVC EP can map to some other service, e.g., Internet Access. However, such services are beyond the scope of this document. Page 21

32 The Carrier Ethernet VLAN PCP (CE-VLAN PCP) is defined as the PCP field of a C-Tagged Service Frame. The Carrier Ethernet VLAN DEI (CE-VLAN DEI) is defined as the DEI filed of a C-Tagged Service Frame. 8.9 Service Level Specification The Subscriber and Service Provider can agree to a contract, called the Service Level Agreement (SLA), that specifies the service level commitments and related business agreements for an Ethernet Service. This document describes the Service Level Specification (SLS) which is the technical details of the service level being offered by the Service Provider to the Subscriber as part of the SLA. The business agreements in an SLA, e.g., penalties for failure to meet the SLS, are beyond the scope of this document. The SLS deals with what the Subscriber experiences. It does not address measurement techniques to estimate the Subscriber experience. Methods for the Service Provider and the Subscriber to monitor the EVC performance to estimate this user experience are beyond the scope of this document. Page 22

33 Ethernet Virtual Connection Service Attributes This section contains Service Attributes that apply to an EVC (Section 8.7). 9.1 EVC ID Service Attribute The value of the EVC ID Service Attribute is a string that is used to identify an EVC within the CEN. 660 [R6] The EVC ID MUST be unique across all EVCs in the CEN. 661 [R7] The EVC ID MUST contain no more than 45 characters [R8] The EVC ID MUST be a non-null RFC 2579 [12] DisplayString but not contain the characters 0x00 through 0x1f The value of the EVC ID Service Attribute is intended for management and control purposes. 8 As an example, the Acme Service Provider might use EVC ACME-MEGAMART to represent the 1898 th EVC in the CEN with the customer for the EVC being MegaMart. 9.2 EVC Type Service Attribute The value of the EVC Type Service Attribute is one of Point-to-Point, Rooted-Multipoint, or Multipoint-to-Multipoint. The value of EVC Type Service Attribute indicates the number of EVC EPs that can be in the EVC and which EVC EPs can communicate with each other. The behaviors for each of these values are as described in Sections 9.2.1, , and For ease of discourse the following terms are defined: The term Point-to-Point EVC is defined as an EVC whose value of the EVC Type Service Attribute = Point-to-Point, The term Rooted-Multipoint EVC is defined as an EVC whose value of the EVC Type Service Attribute = Rooted-Multipoint, and The term Multipoint-to-Multipoint EVC is defined as an EVC whose value of the EVC Type Service Attribute = Multipoint-to-Multipoint. Point-to-Point EVC [R9] When the value of the EVC Type Service Attribute = Point-to-Point, exactly two Root EVC EPs MUST be in the EVC. 7 The limit of 45 characters is intended to establish limits on field lengths in existing or future protocols that will carry the identifier. 8 For example, see Section 8.1 of MEF [28] Page 23

34 The rules under which an ingress Service Frame is delivered to the destination Root EVC EP are specific to the particular service definition. Figure 3 illustrates two Point-to-Point EVCs. R R R Service Provider CEN R Multipoint EVCs UNI R Root EVC End Point EVC Figure 3 Point-to-Point EVCs An EVC that can associate two or more EVC EPs is called a Multipoint EVC. A Multipoint EVC associating two EVC EPs is different from a Point-to-Point EVC because additional EVC EPs can be added to the Multipoint EVC Rooted-Multipoint EVC The value of the EVC EP Role Service Attribute (Section 11.3) for each EVC EP associated by a Rooted-Multipoint EVC has the value of either Root or Leaf. At a Root EVC EP, ingress Service Frames do not have any restrictions as to the Roles of egress EVC EPs for their resulting egress Service Frames. In contrast, at a Leaf EVC EP, ingress Service Frames are restricted to Root EVC EPs for their resulting egress Service Frames [R10] In a Rooted-Multipoint EVC, at least one of the EVC EPs MUST be a Root EVC EP A Rooted-Multipoint EVC that associates only Root EVC EPs is different from a Point-to-Point EVC and a Multipoint-to-Multipoint EVC in that one or more Leaf EVC EPs can be added to the Rooted-Multipoint EVC [R11] For a Rooted-Multipoint EVC, if an egress Service Frame mapped to a Leaf EVC EP results from an ingress Service Frame mapped to an EVC EP in the EVC, the ingress EVC EP MUST be a Root EVC EP. Page 24

35 If an ingress Service Frame at a UNI that is mapped to a Leaf EVC EP is delivered to an egress UNI via a Leaf EVC EP, [R11] is violated. Thus [R11] means that ingress Service Frames at a UNI mapped to a Leaf EVC EP can be delivered to only Root EVC EPs. Ingress Service Frames at a UNI mapped to a Root EVC EP can be delivered to any of the other EVC EPs associated by the Rooted-Multipoint EVC. The rules under which a frame is delivered to a UNI in the EVC are specific to the particular service definition. Typically, a single ingress Service Frame with a broadcast or multicast Destination Address mapped to a Root EVC EP would be replicated in the Carrier Ethernet Network and a single copy would be delivered to each of the other UNIs where there is an EVC EP that is in the EVC. This kind of delivery would also typically apply to a Service Frame for which the CEN has not yet learned an association of the destination MAC address with an EVC EP. Figure 4 illustrates a Rooted-Multipoint EVC with one Root EVC EP. Service Provider CEN L R L UNI R Root EVC End Point EVC L Leaf EVC End Point Broadcast, multicast, and unknown unicast Known unicast Broadcast, multicast, and unicast Figure 4 Rooted-Multipoint EVC Example Page 25

36 Multipoint-to-Multipoint EVC [R12] When the value of the EVC Type Service Attribute = Multipoint-to-Multipoint, all EVC EPs in the EVC MUST be Root EVC EPs Each EVC EP associated by a Multipoint-to-Multipoint EVC is a Root EVC EP. In a Multipointto-Multipoint EVC, the rules under which a frame is delivered to an EVC EP in the EVC are specific to the particular service definition. Typically, a single ingress Service Frame with a broadcast or multicast Destination Address at a given EVC EP would be replicated in the Carrier Ethernet Network and a single copy would be delivered to each of the other EVC EPs in the EVC. This kind of delivery would also typically apply to a Service Frame for which the CEN has not yet learned an association of the destination MAC address with an EVC EP. Figure 5 illustrates a Multipoint-to-Multipoint EVC. UNI B Service R Provider CEN R Service Provider CEN UNI A R R UNI C R R UNI D UNI R Root EVC End Point EVC Figure 5 Multipoint-to-Multipoint EVC 9.3 EVC EP List Service Attribute 9 The value of the EVC EP List Service Attribute is a list of EVC EP ID Service Attribute (Section 11.1) values. The list contains one EVC EP ID Service Attribute value for each EVC EP associated by the EVC.EP 735 [R13] An EVC MUST associate at most one EVC EP at a given UNI [R13] means that an ingress Service Frame at a UNI that is mapped to an EVC EP cannot result in an egress Service Frame at that UNI, i.e., hairpin switching is prohibited. 9 This Service Attribute replaces the UNI List Service Attribute in MEF 10.3 [18]. Page 26

37 EVC Maximum Number of EVC EPs Service Attribute 10 The value of the EVC Maximum Number of EVC EPs Service Attribute is a non-negative integer. The value is the upper bound on the number of EVC EPs that can be associated by the EVC [R14] [R15] For a Point-to-Point EVC, the value of the EVC Maximum Number of EVC EPs Service Attribute MUST be two. For a Multipoint EVC, the value of the EVC Maximum Number of EVC EPs Service Attribute MUST be three or greater EVC Data Service Frame Disposition Service Attribute 11 The value of the EVC Data Service Frame Disposition Service Attribute is a 3-tuple of the form u, m, b where each element in the 3-tuple has the value Discard, Deliver Unconditionally, or Deliver Conditionally. The value of u in the 3-tuple applies to ingress Unicast Data Service Frames. The value m in the 3-tuple applies to ingress Multicast Data Service Frames. The value of b in the 3-tuple applies to ingress Broadcast Data Service Frames. The EVC Data Service Frame Disposition Service Attribute applies to any ingress Data Service Frame that is not discarded per [R77], [R112], [R93], [R95], [R146], [R148], [R149], [R150], [D1], [D2], or [D7]. The dispositions corresponding to each element value are: Discard: The Data Service Frame is discarded. Deliver Unconditionally: The Data Service Frame is delivered to all EVC EPs other than the ingress EVC EP provided [R11] is satisfied. This might be the behavior of a Point-to-Point EVC Deliver Conditionally: The Data Service Frame is delivered to one or more of the other EVC EPs other than the ingress EVC EP EPif certain conditions are met, provided [R11] is satisfied. Examples of Deliver Conditionally include: MAC Address learning where the destination MAC Address is known by the CEN to be at a given EVC EP, Broadcast throttling where some Broadcast Data Service Frames are dropped in order to limit the amount of such traffic, Multicast pruning where some Multicast Data Service Frames are dropped in order limit the amount of such traffic, and MAC Address filtering where Data Service Frames with certain MAC Addresses are discarded. 10 This Service Attribute replaces the Maximum Number of UNIs Service Attribute in MEF 10.3 [18]. 11 In MEF 10.3 [18] this Service Attribute is called Data Service Frame Disposition Service Attribute. Page 27

38 [R16] When an element in the 3-tuple = Deliver Conditionally, the conditions that determine whether an ingress Data EI Frame is delivered or discarded MUST be agreed to by the Subscriber and Service Provider Note that the disposition of ingress Unicast Data Service Frames can be different than the disposition of ingress Multicast Data Service Frames which in turn can be different than the disposition of ingress Broadcast Data Service Frames. Note that this is a description of the ideal service. Data Service Frames that should be delivered might be discarded due to network failure or congestion conditions. See the EVC Related Performance Service Attributes in Section 9.10 and Section 12. The following requirements mandate which fields of a Data Service Frame cannot be changed from ingress to egress. The requirements on the format of Service Frames are in Section [R17] If the egress Data Service Frame resulting from an ingress Tagged Data Service Frame is also a C-Tagged Service Frame then fields in the egress Data Service Frame MUST be unchanged as indicated in Figure 6. Ingress Data Service Frame Destination Address Source Address TCI Length/Type MAC Client Data Pad Frame Check Sequence Unchanged Can change Egress Data Service Frame Destination Address Source Address TCI Length/Type MAC Client Data Pad Frame Check Sequence [R18] If present, length unchanged Figure 6 Tagged In to Tagged Out Data Service Frame Transparency If the egress Data Service Frame resulting from an ingress Tagged Data Service Frame is an Untagged Service Frame then fields in the egress Data Service Frame MUST be unchanged as indicated in Figure 7. Page 28

39 Ingress Data Service Frame Destination Address Source Address TCI Length/Type MAC Client Data Pad Frame Check Sequence Unchanged Can change Egress Data Service Frame Destination Address Source Address Length/Type MAC Client Data Pad Frame Check Sequence [R19] If present, can change Figure 7 Tagged In to Untagged Out Data Service Frame Transparency If the egress Data Service Frame resulting from an ingress Untagged Data Service Frame is a Tagged Data Service Frame then fields in the egress Data Service Frame MUST be unchanged as indicated in Figure 8. Ingress Data Service Frame Destination Address Source Address Length/Type MAC Client Data Pad Frame Check Sequence Unchanged Can change Egress Data Service Frame Destination Address Source Address TCI Length/Type MAC Client Data Pad Frame Check Sequence [R20] If present, can change Figure 8 Untagged In to Tagged Out Data Service Frame Transparency 12 If the egress Data Service Frame resulting from an ingress Untagged Data Service Frame is also an Untagged Service Frame then fields in the egress Data Service Frame MUST be unchanged as indicated in Figure Clause of IEEE Std [4] states that the Pad Field contains arbitrary bits. This document does not constrain the CEN to preserve these bits. Page 29

40 Ingress Data Service Frame Destination Address Source Address Length/Type MAC Client Data Pad Frame Check Sequence Egress Data Service Frame Destination Address Source Address Length/Type MAC Client Data Pad Frame Check Sequence Unchanged Can change If present, length unchanged Figure 9 Untagged In to Untagged Out Data Service Frame Transparency Specific attributes of an EVC can enforce conditions that additional fields must be identical at ingress and egress. See Sections 9.6, 9.7, and EVC CE-VLAN ID Preservation Service Attribute 13 The value of the EVC CE-VLAN ID Preservation Service Attribute is either Enabled or Disabled. When the value is Enabled, there are restrictions on whether the VLAN ID field in Data Service Frames can be modified. The details depend on the values of the All-to-One Bundling Service Attribute (Section 10.11) [R21] When an EVC has the value of the CE-VLAN ID Preservation Service Attribute = Enabled, and an ingress Data Service Frame at a UNI results in an egress Service Frame at another UNI, the relationship between the ingress Data Service Frame and the egress Service Frame MUST be as specified in Table In MEF 10.3 [18] this Service Attribute is called CE-VLAN ID Preservation Service Attribute. Page 30

41 All to One Bundling Service Attribute 14 Ingress Service Frame Requirements on Egress Service Frame 814 Enabled at all UNIs in the EVC Disabled at all UNIs in the EVC Untagged Tagged Untagged Priority Tagged VLAN Tagged Untagged Tagged with the VLAN ID equal to the VLAN ID in the Tag on the ingress Service Frame No preservation restrictions No preservation restrictions If the Egress Service Frame is VLAN Tagged, it has a VLAN ID equal to the VLAN ID in the Tag on the ingress Service Frame. Table 5 Required CE-VLAN ID Preservation Behavior Note that in a multipoint EVC, if a Data Service Frame is delivered to multiple egress UNIs, it is possible that the VLAN ID is only required to be preserved at some of them. This can occur if CE-VLAN ID value 0 is mapped to an EVC EP for the EVC at some UNIs but not others. Note that when the Subscriber UNI All to One Bundling Service Attribute value = Disabled at all UNIs in the EVC and the EVC CE-VLAN ID Preservation Service Attribute = Enabled, if at all EVC EPs in the EVC, the value 0 is not included in the value of EVC EP Map Service Attribute (Section 11.4), then all VLAN Tagged Data Service Frame will have their CE-VLAN ID preserved Editor Note 7: [R22] The original proposal to assign 0 as the CE-VLAN ID value for Untagged and Priority Tagged Service Frames did not modify the following requirement. The Editor has modified it by adding non-zero. See [R110]. When an EVC includes an EVC EP to which more than one non-zero CE- VLAN ID value is mapped by the EVC EP Map Service Attribute (Section 11.4), the EVC MUST have the value of the EVC CE-VLAN ID Preservation Service Attribute = Enabled Note that, per Table 5, there is no mandate for CE-VLAN ID Preservation for ingress Untagged Service Frames and Priority Tagged Service Frames at a UNI except in the case where the value of the Subscriber UNI All to One Bundling Service Attribute = Enabled. An obvious benefit of the value of the EVC CE-VLAN ID Preservation Service Attribute = Enabled is enhanced operational simplicity. For example, for a Subscriber connecting multiple campuses using IEEE Std 802.1Q 2014 bridges, the feature obviates the task of renumbering VLANs in different corporate campuses. 14 Per [R81], all UNIs in an EVC are mandated to have the same value of the Subscriber UNI All to One Bundling Service Attribute. Page 31

42 EVC CE-VLAN PCP Preservation Service Attribute 15 The value of the EVC CE-VLAN PCP Preservation Service Attribute is either Enabled or Disabled [R23] In an EVC with the value of the EVC CE-VLAN PCP Preservation Service Attribute = Enabled, if an ingress C-Tagged Service Frame that is mapped to an EVC EP in the EVC results in and egress C-Tagged Service Frame, the CE- VLAN PCP value in the egress C-Tagged Service Frame MUST be equal to the CE-VLAN PCP value in the ingress C-Tagged Service Frame Note that [R23] does not apply to ingress Untagged Service Frames. 9.8 EVC CE-VLAN DEI Preservation Service Attribute The value of the EVC CE-VLAN DEI Preservation Service Attribute is either Enabled or Disabled. The EVC CE-VLAN DEI Preservation Service Attribute can be used to preserve the value of the DEI field in C-Tagged Service Frames across an EVC [R24] In an EVC with the value of the EVC CE-VLAN DEI Preservation Service Attribute = Enabled, if an ingress C-Tagged Service Frame that is mapped to an EVC EP in the EVC results in and egress C-Tagged Service Frame, the CE- VLAN DEI value in the egress C-Tagged Service Frame MUST be equal to the CE-VLAN DEI value in the ingress C-Tagged Service Frame Note that [R24] does not apply to ingress Untagged Service Frames. 9.9 EVC List of Class of Service Names Service Attribute The value of the EVC List of Class of Service Names Service Attribute is a list of Class of Service Names (which may include one or more of the CoS Labels defined in MEF 23.2 [25]). Each ingress Service Frame is assigned a Class of Service Name from this list via the EVC EP Ingress Class of Service Map Service Attribute as described in Section The Class of Service Name that is assigned to a frame indicates the Performance Metric Objectives that apply to the frame under appropriate conditions as detailed in Section 9.10, and is used to determine how to set certain fields in an egress Service Frame that results from this ingress Service Frame, as described by the EVC EP Egress Map Service Attribute (Section 11.7). Table 6 shows an example of the value of the EVC List of Class of Service Names Service Attribute. Note that a frame assigned the Class of Service Name Discard is to be discarded per [R112]. 15 In MEF 10.3 [18] this Service Attribute is called CE-VLAN CoS Preservation Service Attribute. Page 32

43 Platinum Gold Silver Discard Table 6 Example value for the EVC List of Class of Service Names Service Attribute Note that the value of the EVC EP Ingress Class of Service Map Service Attribute (Section 11.5) can be such that the Class of Service Names for Service Frames mapped to an EVC EP does not include one or more of the entries in the value of the EVC List of Class of Service Names Service Attribute for the EVC that associates the EVC EP. In other words, not all entries in the value of the EVC List of Class of Service Names Service Attribute for an EVC need to be available at every EVC EP associated by the EVC EVC Service Level Specification Service Attribute The value of the EVC Service Level Specification Service Attribute (SLS) is either None or a 3- tuple of the form t s, T, CN where: t s is a time that represents the date and time for the start of the SLS. T is a time interval, e.g., 1 month, 2 weeks, that is used in conjunction with t s to specify time intervals for determining when Performance Metric Objectives are met. Note that the units for T are not constrained; in particular, 1 month is an allowable value for T, corresponding to a calendar month, e.g. from midnight on the 10th of one month up to but not including midnight the 10th of the following month. CN is a list of 5-tuples of the form CoS_Name, t, C, n, PM where CoS_Name is a Class of Service Name contained in the value of the EVC List of Class of Service Names Service Attribute (Section 9.9) and is not Discard. t is a time interval much smaller than T, e.g., 10 seconds. C is a real number in the range [0,1] 16 used as a threshold to determine whether a given time interval t k has high loss. n is an integer 1, used to identify how many consecutive t intervals must have high loss to trigger a change in Availability. PM is a list where each element in the list consists of a Performance Metric Name, a list of parameter values specific to the definition of the Performance Metric, and Performance Metric Objective. 16 Throughout this document, numeric ranges are denoted as follows: z in [x, y] means x z y, z in [x, y) means x z < y, z in (x, y] means x < z y, and z in (x, y) means x < z < y. Page 33

44 897 [R25] A Class of Service Name MUST appear at most once in the value of CN A Performance Metric is a quantitative characterization of Service Frame delivery quality experienced by the Subscriber. This section specifies the following Performance Metrics all of which apply to a single EVC: 1. One-way Frame Delay Performance Metric (Section ), 2. One-way Mean Frame Delay Performance Metric (Section ), 3. One-way Frame Delay Range Performance Metric (Section ), 4. One-way Inter-Frame Delay Variation Performance Metric (Section ), 5. One-way Frame Loss Ratio Performance Metric (Section ), 6. One-way Availability Performance Metric (Section ), 7. One-way High Loss Intervals Performance Metric (Section ), 8. One-way Consecutive High Loss Intervals Performance Metric (Section ), and 9. One-way Group Availability Performance Metric (Section ). Section 12 defines the Performance Metric for the Multiple EVC Service Level Specification Service Attribute. Each Performance Metric has an associated Performance Metric Objective whose value reflects the promised Service Frame delivery quality. For example, for the One-way Frame Delay Performance Metric (Section ), a Performance Metric Objective of 20 ms means that the mean Service Frame delay experienced by Subscriber is promised (by the Service Provider) to be less than or equal to 20 ms. The EVC Service Level Specification Service Attribute (SLS) is the technical specification of the service level agreed to by the Service Provider and the Subscriber. For any given SLS, a Performance Metric and related Performance Metric Objective may or may not be specified [R26] If PM contains an entry with a given Performance Metric Name, then the entry MUST specify the related parameters and the Performance Metric Objective for that Performance Metric as specified in the following sections These Performance Metrics describe the performance experienced by the Subscriber who is the user of the EVC. Methods for the Service Provider and the Subscriber to monitor the EVC performance to estimate this user experience are beyond the scope of this document. PM can contain multiple entries with a given Performance Metric Name, but one or more of the parameter values associated with each objective for a given Performance Metric Name need to be different from each other. For example, PM could contain two objectives for the One-way Page 34

45 Frame Delay Performance Metric each corresponding to a different value of the percentile P d (see Section ) Key SLS Definitions, Concepts, and Notation This section describes definitions, concepts, and notation used throughout Section Common Parameters The parameter S is used in most of the Performance Metric definitions. S is a non-empty set of ordered EVC EP pairs taken from the value of the EVC EP List Service Attribute (Section 9.3). Whenever S is used it is assumed that the EVC EPs in the value of the EVC EP List Service Attribute are numbered 1 to m and thus S { i, j i = 1,, m, j = 1,, m, i j}, S [R27] Each ordered EVC EP pair x, y S, at least one the EVC EPs MUST be a Root EVC EP (Section 11.3) The parameter CoS_Name is used in all of the Performance Metric definitions. CoS_Name takes on a value of one of the entries in the value of the EVC List of Class of Service Names Service Attribute (Section 9.9) other than Discard. Consider CN = Gold, 10 seconds, 0.5,4, PM, Figure 10 shows an example value for PM in this 5-tuple. One-way Frame Loss Ratio, { 1,2 }, 0.01% PM = { One-way Frame Loss Ratio, { 2,1 }, 0.01% } Figure 10 Example of a Value for PM In this example, the first item in each element is the Performance Metric Name, i.e., One-way Frame Loss Ratio (Section ). The second item is S. The third item is the Performance Metric Objective. In this example, S varies from entry to entry. Note that the Class of Service Name for this PM is Gold per the value of CN. Figure 11 shows an example value for PM in the case of CN = Siver, 10 seconds, 0.5,4, PM. Note that the objective (0.05%) for Silver is different than it is for Gold (0.01%) in Figure 10. One-way Frame Loss Ratio, { 1,2 }, 0.05% PM = { One-way Frame Loss Ratio, { 2,1 }, 0.05% } Figure 11 Another Example of a Value for PM Time Interval Sequences, Available Time, and Maintenance Interval For each CoS_Name in CN, the time interval sequence { t k, k = 0,1,2, } is used where t k = [t 0 + k t, t 0 + (k + 1) t) t is from the item in CN with CoS_Name, and t 0 is the time at which the EVC is first turned up. Note that t can be different for different Class of Service Names. Page 35

46 958 For the SLS, the sequence {T l, l = 0,1,2, } is used where T l = [t s + lt, t s + (l + 1)T) Each element of {T l } is used for assessing the success of the EVC in meeting the Performance Metric Objectives of the SLS. For most of the Performance Metrics in the SLS, the Performance Metric Objective only applies to ingress Service Frames that arrive at the Service during Available Time. Available Time is defined for each CoS_Name in CN as follows. For a given i, j S and a given CoS_Name in CN, each t k is defined to be either Available or Unavailable and this is represented by A i,j ( t k ) where A i,j ( t k ) = 1 means that t k is Available and A i,j ( t k ) = 0 means that t k is Unavailable. Informally, Available Time is based on frame loss during a sequence of consecutive small time intervals. When the previous sequence was defined as available, if the frame loss is high for each small time interval in the current sequence, then the small time interval at the beginning of the current sequence is defined as unavailable; otherwise it is defined as available. On the other hand, when the previous sequence was defined as unavailable, if frame loss is low for each small time interval in the current sequence, then the small time interval at the beginning of the current sequence is defined as available; otherwise, it is defined as unavailable. The formal definition follows. The definition of A i,j ( t k ) is based on the frame loss ratio function flr i,j ( t k ) which is defined as follows. i,j 976 For a given i, j S, a given CoS_Name, and a t k, let I tk be the number of ingress Service 977 Frames that meet the following conditions: The first bit of each Service Frame arrives at the UNI where EVC EP i is located and it s time of arrival is within the time interval t k, Each Service Frame maps to EVC EP i via an EVC EP Map Service Attribute (Section 11.4). Each Service Frame should be delivered to the EVC EP j according to the EVC Data Service Frame Disposition Service Attribute (Section 9.5 ), Each Service Frame is not discarded per [R77], [R112], [D1], [D2], [D7], [O2], or any of the conditions specified per the EVC Data Service Frame Disposition Service Attribute (Section 9.5), Each Service Frame has the given CoS_Name, Each Service Frame that is subject to an ingress Bandwidth Profile has an Ingress Bandwidth Profile Color Declaration equal to Green, and Page 36

47 Each ingress Service Frame that is not subject to an ingress Bandwidth Profile has the Color Green per the EVC EP Color Map Service Attribute (Section 11.6) Let E i,j tk be the number of unique (not duplicate) egress Service Frames where each Service Frame is the first, unerrored egress Service Frame that is mapped to the EVC EP j at the UNI i,j where EVC EP j is located that results from a frame counted in I tk. Then flr i,j ( t k ) = { (I t k i,j i,j E tk i,j I tk 0 otherwise i,j ) if I tk In the case of a Multipoint-to-Multipoint EVC or a Rooted-Multipoint EVC, the Subscriber and the Service Provider can agree to define flr i,j ( t k ) as flr i,j ( t k ) = { (I tk i,j i,j E tk i,j I tk 0 otherwise i,j ) if I tk where i,j = I i,j I tk tk D and D is the number of frames discarded by the Service Provider in order to conform to either the line rate of the UNI where EVC EP j is located or an egress Bandwidth Profile (if one is used) at the UNI where EVC EP j is located. Such frame drops may occur anywhere in the network, not just near the egress UNI. One example of this could be where an egress Bandwidth profile is implemented by applying a policer or shaper on a link within the network. Another example of this could be where Green frames for this EVC and Class of Service Name that should be delivered to the UNI with EVC EP j exceed the line rate on a link within the network, provided the line rate of that link is greater than or equal to the line rate of the UNI. Good traffic engineering principles would suggest dropping such excessive frames as close to the ingress as possible. This adjustment is meant to account for a focused overload of traffic sent to the UNI where EVC EP j is located. The details of such an adjustment are beyond the scope of this document. A i,j ( t k ) is defined in Figure 12 for k = 0,1,2,. Page 37

48 Begin No 1 A i t or k 0, j k 1 Yes /*Transition to Available if next n intervals have low loss*/ /*Check availability of previous interval*/ /*Transition to Unavailable if next n intervals have high loss*/ flr t, C i, j m m k, k 1,..., k n 1 Yes No flr t, C i, j m m k, k 1,..., k n 1 No A i t 1, j k Yes A i t 0, j k Figure 12 Flowchart Definition of A i,j ( t k ) for a Given Class of Service Name An alternative way of expressing A i,j ( t k ) for k = 0 is A i,j ( t 0 ) = { 0 if flr i,j ( t m ) > C for all m = 0,1,, n 1 1 otherwise 1013 and for k = 1,2, is A i,j ( t k ) 0 if A i,j ( t k 1 ) = 1 and flr i,j ( t m ) > C for all m = k, k + 1,, k + n 1 = { 1 if A i,j ( t k 1 ) = 0 and flr i,j ( t m ) C for all m = k, k + 1,, k + n 1 A i,j ( t k 1 ) otherwise In the event of a conflict between the above equations and Figure 12, the content of Figure 12 is controlling. Recall that { t k, k = 0,1, }, C, and n can be different for different Class of Service Names. The availability for t k is based on the frame loss ratio during the short interval and each of the following n 1 short intervals and the availability of the previous short time interval. In other words, a sliding window of width n t is used to define availability. This use of a sliding window is similar to that of ITU-T Y [8] Page 38

49 Figure 13 presents an example of the determination of the availability for the small time intervals with a sliding window of n = 10 small time intervals. t 0 nt A t 1 A i t 0 A i t 1 i, j k, j k nt, j k Time n 10 flr i, j t C m flr i, j t C m Figure 13 Example of the Determination of A i,j ( t k ) for a Given Class of Service Name As can be seen below, the definition of Available Time excludes small time intervals that intersect a Maintenance Interval. A Maintenance Interval is a time interval agreed to by the Subscriber and Service Provider during which the EVC may not perform well or at all. Examples of a Maintenance Interval include: A time interval during which the Service Provider may disable the EVC for network maintenance such as equipment replacement, A time interval during which the Subscriber and Service Provider may perform joint fault isolation testing, and A time interval during which the Service Provider may change service features and making the changes may disrupt the EVC Figure 14 shows an example of a Maintenance Interval. Maintenance Interval t 0 nt X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X nt A t 1 A i t 0 A i t 1 i, j k, j k, j k Time X n 10 flr flr i, j i, j t C m t C m t k intersects the Maintenance Interval Figure 14 Example of a Maintenance Interval Page 39

50 Let W Tl be the set of all t k s contained in T l that do not intersect a Maintenance Interval and let W Tl represent the number of elements in the set W Tl. i,j 1042 Available Time for the ordered EVC EP pair i, j, CoS_Name, and T l denoted by AT Tl, is de fined as i,j AT Tl = { tk t k W Tl, A i,j ( t k ) = 1} 1044 i,j Unavailable Time, denoted UT Tl, is defined as i,j UT Tl = { tk t k W Tl, A i,j ( t k ) = 0} Note that a t k that intersects a Maintenance Interval is not included in Available Time and not included in Unavailable Time. Note that the definition of W Tl means that the boundaries of T l and the boundaries of a Maintenance Interval do not have to align with the boundary of a t k Qualified Service Frames The Performance Metrics, with the exception of the One-way Availability Performance Metric, apply to Qualified Service Frames. Qualified Service Frames are defined as every Service Frame that satisfies the following criteria for a given i, j S, a given CoS_Name, and a given T l : Each Service Frame ingresses at the UNI where EVC EP i is located, Each Service Frame maps to EVC EP i via an EVC EP Map Service Attribute (Section 11.4). Each Service Frame should be delivered to the EVC EP j according to the EVC Data Service Frame Disposition Service Attribute (Section 9.5), Each Service Frame is not discarded per [R77], [R112], [D1], [D2], [D7], [O2], or any of the conditions specified per the EVC Data Service Frame Disposition Service Attribute (Section 9.5), The first bit of each Service Frame arrives at the ingress UNI within the time interval T l, and within a time interval t k that is in Available Time, i.e., t k i,j (Section ), AT Tl Each Service Frame has the given CoS_Name, Each Service Frame that is subject to an ingress Bandwidth Profile has an Ingress Bandwidth Profile Color Declaration equal to Green, and Page 40

51 Each Service Frame that is not subject to an ingress Bandwidth Profile has the Color Green per the EVC EP Color Map Service Attribute (Section 11.6) One-way Frame Delay The One-way Frame Delay for a Service Frame that ingresses at UNI 1 and results in a Service Frame that egresses at UNI 2 is defined as the time elapsed from the reception of the first bit of the ingress Service Frame at UNI 1 until the transmission of the last bit of the first corresponding egress Service Frame at UNI 2. If the Service Frame is erroneously duplicated in the Operator CEN and multiple copies delivered to UNI 2, the delay is based on the first such copy delivered. This definition is illustrated in Figure 15. First bit of the Service Frame arrives at the ingress UNI Last bit of the Service Frame arrives at the ingress UNI First bit of the Service Frame arrives at the egress UNI Last bit of the Service Frame arrives at the egress UNI t t 1 t 2 t 3 Increasing Time Figure 15 One-way Frame Delay for Service Frame The definition of One-way Frame Delay for a Service Frame is the one-way 17 delay that includes the delays encountered as a result of transmission of the Service Frame across the ingress UNI (t 1 t 0 ) and egress UNI (t 3 t 2 ) as well as that introduced by the CEN (t 2 t 1 ). When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical for the ingress UNI, (t 1 t 0 ) = the length of the Service Frame divided by the line rate of the physical layer. When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual for the ingress UNI, the value of (t 1 t 0 ) depends on the details of the Subscriber Virtual Frame Service Attribute (Section 10.3) exchange across the ingress UNI and is beyond the scope of this document. Similar comments apply to the value of (t 3 t 2 ) at the egress UNI One-way Frame Delay Performance Metric This section defines the One-way Frame Delay Performance Metric [R28] The SLS MUST define the One-way Frame Delay Performance Metric as follows: 17 One-way delay is difficult to measure and therefore one way delay may be approximated from two way measurements. However measurement techniques are beyond the scope of this document. Page 41

52 i,j Let d T l d represent the Pd -Percentile, expressed as a percentage in (0, 100], of One-way Frame Delay for all Qualified Service Frames 18 mapped to the EVC EP j delivered to the egress UNI where EVC EP j is located resulting from an ingress frame mapped to the EVC EP i at the UNI where EVC EP i is located. If there are no such egress frames, then d T i,j l d = Then the One-way Frame Delay Performance Metric MUST be defined as the i,j maximum value of all of the values d T l d for i, j S i,j To restate the definition mathematically, let D Tl be the set of one-way Frame Delay values for 1099 all Qualified Service Frames mapped to the EVC EP j at the UNI where EVC EP j is located re sulting from an ingress frame mapped to the EVC EP i at the UNI where EVC EP i is located i,j i,j i,j i,j i,j D Tl can be expressed as DTl = { d1, d2,, d NTl i,j } where dk i,j is the one-way Frame Delay of the k th i,j i,j 1102 frame and where N Tl is the number of elements in DTl. Define d 1103 P d > 0 as i,j d T l d = i,j min {d D Tl Pd 100 i,j I (d, d k { 0 otherwise N Tl N T i,j k=1 i,j ) i,j } if N Tl 1 i,j T l d for 1104 where I(d, d k ) is an indicator function defined by I(d, d k ) = { 1 if d d k 0 otherwise i,j d T l d is the minimal delay during the time internal Tl that P d percent of the frames do not exceed. Then the One-way Frame Delay Performance Metric for an EVC can be expressed as i,j d T l,s = max { d T l d i, j S} Table 7 shows what is contained in a PM entry for the One-way Frame Delay Performance Metric. 18 The Class of Service Name used in the definition of Qualified Service Frames is the CoS_Name used in the CN 5- tuple in which the Performance Metric resides. Page 42

53 Item Value Performance Metric Name One-Way Frame Delay Performance Metric S Non-empty subset of the ordered pairs of EVC EPs P d A percentage in (0, 100] d Performance Metric Objective in time units > 0 [R29] Table 7 PM Entry for the One-way Frame Delay Performance Metric The SLS MUST define the One-way Frame Delay Performance Metric Objective as met over T l for a PM entry of the form in Table 7 if and only if d T l,s d. One-way Mean Frame Delay Performance Metric 1116 This Section defines the One-way Mean Frame Delay Performance Metric [R30] The SLS MUST define the One-way Mean Frame Delay Performance Metric as follows: 1119 i,j Let μ T l represent the arithmetic mean of One-way Frame Delay for all Qualified 1120 Service Frames 19 mapped to the EVC EP j delivered to the UNI where EVC EP j 1121 is located resulting from an ingress frame mapped to the EVC EP i at the UNI 1122 where EVC EP i is located. If there are no such egress frames, then μ T l = Then the One-way Mean Frame Delay Performance Metric MUST be defined as i,j the maximum value of all of the values μ T l for i, j S i,j To restate the definition mathematically, let D Tl be the set of one-way Frame Delay values for 1127 all Qualified Service Frames mapped to the EVC EP j at the UNI where EVC EP j is located re sulting from an ingress frame mapped to the EVC EP i at the UNI where EVC EP i is located D i,j Tl can be expressed as D i,j Tl = { d i,j 1, d i,j 2,, d i,j NTl i,j } where d k i,j is the one-way Frame 1130 Delay of the k th i,j i,j i,j frame and where N Tl is the number of elements in DTl. Define μ T l as i,j μ T l = 1 N Tl i,j N Tl i,j d k k=1 i,j { 0 if N Tl = 0 i,j if NTl i,j > Then the One-way Mean Frame Delay Performance Metric for an EVC can be expressed as 19 The Class of Service Name used in the definition of Qualified Service Frames is the CoS_Name used in the CN 5- tuple in which the Performance Metric resides. Page 43

54 μ T l,s = max { μ T i,j l i, j S} Table 8 shows what is contained in a PM entry for the One-way Mean Frame Delay Performance Metric. Item Value Performance Metric Name One-way Mean Frame Delay Performance Metric S Non-empty subset of the ordered pairs of EVC EPs μ Performance Metric Objective in time units > 0 Table 8 PM Entry for the One-way Mean Frame Delay Performance Metric [R31] The SLS MUST define the One-way Mean Frame Delay Performance Metric Objective as met over T l for a PM entry of the form in Table 8 if and only if μ T l,s μ. One-way Frame Delay Range Performance Metric 1140 This Section defines the One-way Frame Delay Range Performance Metric [R32] The SLS MUST define the One-way Frame Delay Range Performance Metric as follows: 1143 i,j i,j i,j i,j Let d T l R = d T l r d min. The term d T l r represents the Pr -Percentile, expressed 1144 as a percentage in (0, 100], of the One-way Frame Delay for all Qualified Service 1145 Frames 20 mapped to the EVC EP j delivered to the egress UNI where EVC EP j is 1146 located resulting from an ingress frame mapped to the EVC EP i at the UNI i,j 1147 where EVC EP i is located. d min is the minimum of the One-way Frame Delays 1148 for all Qualified Service Frames delivered to the UNI where EVC EP j is located 1149 resulting from an ingress frame at the UNI where EVC EP i is located. If there are 1150 i,j no such egress frames, then d T l R = Then the One-way Frame Delay Range Performance Metric MUST be defined as i,j the maximum value of all of the values of d T l R for i, j S i,j To restate the definition mathematically, let D Tl be the set of one-way Frame Delay values for 1154 all Qualified Service Frames mapped to the EVC EP j at the UNI where EVC EP j is located re sulting from an ingress frame mapped to the EVC EP i at the UNI where EVC EP i is located i,j i,j i,j i,j i,j D Tl can be expressed as DTl = { d1, d2,, d NTl i,j } where dk i,j is the one-way Frame 20 The Class of Service Name used in the definition of Qualified Service Frames is the CoS_Name used in the CN 5- tuple in which the Performance Metric resides. Page 44

55 Delay of the k th i,j i,j 1157 frame and where N Tl is the number of elements in DTl. With dmin i,j i,j 1158 min {d D Tl }, define d T l R as i,j i,j i,j ( i,j d T d T l R = { l r dmin) if NTl > 0 i,j 0 if N Tl = 0 i,j = 1159 where i,j d T l r = min { { 0 otherwise i,j d D Tl Pr 100 i,j I (d, d k N Tl i,j N Tl k=1 i,j ) } i,j if N Tl and where I(d, d k ) is an indicator function defined by I(d, d k ) = { 1 if d d k 0 otherwise 1161 Then the One-way Frame Delay Range Performance Metric for an EVC can be expressed as d T l R,S = max { d T i,j l R i, j S } Table 9 shows what is contained in a PM entry for the One-way Frame Delay Range Performance Metric. Item Value Performance Metric Name One-way Frame Delay Range Performance Metric S Non-empty subset of the ordered pairs of EVC EPs P r A percentile > 0 d R Performance Metric Objective in time units > 0 Table 9 PM Entry for the One-way Frame Delay Range Performance Metric [R33] The SLS MUST define the One-way Frame Delay Range Performance Metric Objective as met over T l for a PM entry of the form in Table 9 if and only if d T l R,S d R. One-way Inter-Frame Delay Variation Performance Metric The One-way Inter-Frame Delay Variation Performance Metric (IFDV) characterizes the difference between the One-way Frame Delays of pairs of selected Service Frames. This definition is analogous to that in RFC3393 [13] where IP packet delay variation is defined. Page 45

56 Let a q be the time of the arrival of the first bit of the q th Service Frame at the ingress UNI and let τ be a short time interval > 0, then the two Service Frames k and l are selected according to the selection criterion: a k a l = τ Let r q be the time Service Frame q is successfully received (last bit of the frame) at the egress UNI and let d q be the delay for Service Frame q, then the difference in the delays encountered by Service Frame k and Service Frame l is given by d k d l. Define d kl = d k d l = (r k a k ) (r l a l ) = (a l a k ) (r l r k ) For k < l, a positive value for d k d l implies that the two Service Frames are closer together at the egress UNI while a negative value implies that the two Service Frames are further apart at the egress UNI. If either or both frames are lost or not delivered due to, for example, FCS violation, then the value d kl is not defined and does not contribute to the evaluation of the One-way Inter- Frame Delay Variation Performance Metric. Figure 16 shows a depiction of the different times that are related to One-way Inter-Frame Delay Variation Performance Metric. k k + 1 l l Ingress Egress k l Time k l k l Figure 16 One-way Inter-Frame Delay Variation Definition [R34] The SLS MUST define the One-way Inter-Frame Delay Variation Performance Metric as follows: i,j Let d Tl be the Pv -percentile, expressed as a percentage in (0, 100], of the d kl s of all Qualified Service Frame pairs where each Qualified Service Frame 21 ingresses at EVC EP i and results in an egress frame at EVC EP j and whose difference in arrival times of the first bit of each frame in the pair at EVC EP i was τ. i,j If there are no such pairs of frames for EVC EP i and EVC EP j, then d Tl = The Class of Service Name used in the definition of Qualified Service Frames is the CoS_Name used in the CN 5- tuple in which the Performance Metric resides. Page 46

57 Then the One-way Inter-Frame Delay Variation Performance Metric MUST be i,j the maximum of the values d Tl for i, j S This definition is in agreement with the IP packet delay variation definition given in RFC3393 [13] where the delay variation is defined as the difference between the one-way delay of two packets selected according to some selection function and are within a given interval [t 1, t 2 ]. The choice of the value for τ can be related to the application timing information. As an example for voice applications where voice frames are generated at regular intervals, τ may be chosen to be few multiples of the inter-frame time. To restate the definition mathematically, let V Tl i,j = { d1 i,j, d2 i,j,, dntl i,j i,j } be the set of the absolute value of delay variations for all eligible pairs of Qualified Service Frames mapped to the EVC EP i from the UNI where EVC EP i is located to the UNI where EVC EP j is located where the difference in the arrival times of the first bit of each frame at the ingress UNI was exactly τ. Define i,j d Tl = min { { 0 otherwise i,j d V Tl Pv 100 i,j I (d, d k N Tl i,j N Tl k=1 i,j ) } i,j if N Tl where I(d, d k ) is an indicator function defined by I(d, d k ) = { 1 if d d k 0 otherwise Then a One-way Inter-Frame Delay Variation Performance Metric for an EVC can be expressed as i,j d Tl,S = max { d Tl i, j S} Table 10 shows what is contained in a PM entry for the One-way Inter-Frame Delay Variation Performance Metric. Page 47

58 1215 Item Value Performance Metric Name One-way Inter-Frame Delay Variation Performance Metric S Non-empty subset of the ordered pairs of EVC EPs P v A percentile > 0 τ A time interval in time units d Performance Metric Objective in time units Table 10 PM Entry for the One-way Inter-Frame Delay Variation Performance Metric [R35] The SLS MUST define the One-way Inter-Frame Delay Variation Performance Metric Objective as met over T l for a PM entry of the form in Table 10 if and only if d Tl,S d. One-way Frame Loss Ratio Performance for an EVC 1220 The One-way Frame Loss Ratio Performance Metric characterizes frame loss as a percentage [R36] The SLS MUST define the One-way Frame Loss Ratio Performance Metric as follows: i,j Let I Tl denote the number of ingress Qualified Service Frames 22 mapped to the EVC EP i at the UNI where EVC EP i is located that should have been delivered to the UNI where EVC EP j is located according to the value of the EVC Data Service Frame Disposition Service Attribute (Section 9.5) i,j Let E Tl be the number of unique (not duplicate) egress Service Frames where 1228 each Service Frame is the first egress Service Frame mapped to the EVC EP j at 1229 i,j the UNI where EVC EP j is located that results from a frame counted in I Tl Define FLR Tl i,j i,j i,j = { (I T ETl l i,j I Tl 0 otherwise i,j ) 100 if I Tl 1. Then the One-way Frame Loss Ratio Performance Metric MUST be defined as i,j FLR Tl,S = max {FLR Tl i, j S} In the case of a Multipoint-to-Multipoint EVC or a Rooted-Multipoint EVC, the Subscriber and i,j the Service Provider can agree to define FLR Tl as 22 The Class of Service Name used in the definition of Qualified Service Frames is the CoS_Name used in the CN 5- tuple in which the Performance Metric resides. Page 48

59 FLR i,j (I Tl Tl = { i,j i,j ETl i,j I Tl 0 otherwise i,j ) 100 if I Tl i,j i,j where I Tl = ITl D and D is the number of frames discarded by the Service Provider, in or der to conform to either the line rate of the UNI where EVC EP j is located or an egress Band width Profile (if one is used) at the UNI where EVC EP j is located. Such frame drops may occur 1237 anywhere in the network, not just near the egress UNI. One example of this could be where an 1238 egress Bandwidth profile is implemented by applying a policer or shaper on a link within the 1239 network. Another example of this could be where Green frames for this EVC and Class of Ser vice Name that should be delivered to the UNI with EVC EP j exceed the line rate on a link 1241 within the network, provided the line rate of that link is greater than or equal to the line rate of 1242 the UNI. Good traffic engineering principles would suggest dropping such excessive frames as 1243 close to the ingress as possible. This adjustment is meant to account for a focused overload of 1244 traffic sent to the UNI where EVC EP j is located. The details of such an adjustment are beyond 1245 the scope of this document Table 11 shows what is contained in a PM entry for the One-way Frame Loss Ratio Performance Metric. Item Value Performance Metric Name One-way Frame Loss Ratio Performance Metric S Non-empty subset of the ordered pairs of EVC EPs L Performance Metric Objective expressed as a percentage Table 11 PM Entry for the One-way Frame Loss Ratio Performance Metric [R37] The SLS MUST define the One-way Frame Loss Performance Metric Objective as met over T l for a PM entry of the form in Table 11 if and only if FLR Tl,S L. One-way Availability Performance Metric The One-way Availability Performance Metric is the percentage of time which is Available Time (Section ). (The precise definition is presented in the following paragraphs.) As an example, suppose the Performance Metric Objective for the One-way Availability Performance Metric is 99.9% when the duration of T l = 30 days. If there is no Maintenance Interval (Section ) this objective will allow the service to be unavailable for approximately 43 minutes out of the 30 days. For a given i, j S, a given CoS_Name, 23 and a given T l, define 23 The Class of Service Name used is the CoS_Name used in the CN 5-tuple in which the Performance Metric resides. Page 49

60 i,j A Tl = { 100 AT i,j T l W Tl 0 otherwise i,j where the sets AT Tl and WTl are defined in Section and represents the number of elements in a set. Note that by the definitions in Section , t k s that intersect a Mainte- i,j nance Interval are not included in the calculation of A Tl [R38] The SLS MUST define the One-way Availability Performance Metric as: A S Tl i,j = min {A Tl i, j S} Table 12 shows what is contained in a PM entry for the One-way Availability Performance Metric. Item Value Performance Metric Name One-way Availability Performance Metric S Non-empty subset of the ordered EVC EP pairs A Performance Metric Objective expressed as a percentage Table 12 PM Entry for the One-way Availability Performance Metric [R39] The SLS MUST define the One-way Availability Performance Metric Objective as met over T l for a PM entry of the form in Table 12 if and only if A S Tl A. One-way High Loss Intervals Performance Metric The One-way High Loss Intervals Performance Metric is a count of the number of t k s that are in Available Time (Section ) for a given T l and that have a high frame loss. When t = 1 second, it is analogous to the definition of Severe Errored Seconds (SES) defined in Section 9 of ITU Recommendation Y.1563 [8]. Section defines a related Performance Metric called the One-Way Consecutive High Loss Intervals Performance Metric. Figure 17 illustrates how the One-way High Loss Intervals Performance Metric and the One-way Consecutive High Loss Intervals Performance Metric fit into the hierarchy of time and other attributes. Page 50

61 SLS Interval, T l Unavailable Time Available Time Maintenance Interval High Loss Intervals Non-High Loss Intervals Consecutive High Loss Intervals Non-Consecutive High Loss Intervals Figure 17 Hierarchy of Time Showing the One-way Resiliency Attributes For a given i, j S and a given CoS_Name, 24 the high loss state of t k contained in T l is represented by H i,j Tl ( t k ) that is defined as H i,j Tl ( t k ) = { 1 if t i,j k AT Tl and flr i,j ( t k ) > C 0 otherwise i,j where AT Tl and flr i,j ( t k ) are defined in Section Recall that { t k, k = 0,1, } and C can be different for different Class of Service Names. i,j 1286 For a given i, j S and a given CoS_Name, the count of High Loss Intervals, HL Tl, is defined 1287 as i,j HL Tl = i,j HTl ( t k ) t k T l [R40] The SLS MUST define the One-way High Loss Intervals Performance Metric as: HL S Tl i,j = max {HL Tl i, j S} 24 The Class of Service Name used is the CoS_Name used in the CN 5-tuple in which the Performance Metric resides. Page 51

62 Table 13 shows what is contained in a PM entry for the One-way High Loss Intervals Performance Metric. Item Value Performance Metric Name One-way High Loss Intervals Performance Metric S Non-empty subset of the ordered EVC EP pairs HL Performance Metric Objective expressed as a non-negative integer Table 13 PM Entry for the One-way High Loss Intervals Performance Metric [R41] The SLS MUST define the One-way High Loss Intervals Performance Metric Objective as met over T l for a PM entry of the form in Table 13 if and only if S HL. HL Tl One-way Consecutive High Loss Intervals Performance Metric The One-way Consecutive High Loss Intervals Performance Metric is a count of the number of runs of consecutive t k s that are in Available Time (Section ) and that have a high frame Loss. When t = 1 second, it is analogous to the definition of Consecutive Severely Errored Seconds defined in Annex B of ITU Recommendation Y.1563 [8] For a given i, j S, a given CoS_Name, 25 a given T l, and an integer p such that 1 p < n the i,j 1303 count of Consecutive High Loss Intervals is denoted by B Tl and defined by the flow chart in 1304 Figure 18. Note that H i,j Tl ( t k ) is defined in Section The Class of Service Name used is the CoS_Name used in the CN 5-tuple in which the Performance Metric resides. Page 52

63 Begin k B Tl i, j 0 max p,min r t r T l /*Counter = 0 at start of T l */ No i, j t 1, q k p 1 k HT l q,..., i, j H T t l Yes 1, k p No Yes /*p consecutive High Loss intervals?*/ /*Existing consecutive run?*/ B i, j T l B i, j T l 1 /*Increment counter*/ k k End No tk T l Yes Figure 18 Determining and Counting Consecutive High Loss Intervals for a Given Class of Service Name Recall that { t k, k = 0,1, }, C, and n can be different for different Class of Service Names. Figure 19 shows an example that depicts the Consecutive High Loss Intervals counting processes when there is no Maintenance Interval. Note that A i,j ( t k ) is defined in Section and i,j ( t k ) is defined in Section H Tl A t t 0 i, j k i, j H T t l i j B, T k nt nt Time n 10, p 3 flr i, j t C m flr i, j t C Figure 19 Example of Counting Consecutive High Loss Intervals m Page 53

64 [R42] The SLS MUST define the One-way Consecutive High Loss Intervals Performance Metric as: B S Tl = max {B i,j Tl i, j S} Table 14 shows what is contained in a PM entry for the One-way Consecutive High Loss Intervals Performance Metric. Item Performance Metric Name S p B Value One-way Consecutive High Loss Intervals Performance Metric Non-empty subset of the ordered EVC EP pairs An integer 1 and < n Performance Metric Objective expressed as a non-negative integer Table 14 PM Entry for the One-way Consecutive High Loss Intervals Performance Metric [R43] The SLS MUST define the One-way Consecutive High Loss Intervals Performance Metric Objective as met over T l for a PM entry of the form in Table 14 if and only if B S Tl B. One-way Composite Performance Metric The One-way Composite Performance Metric is expressed as the percentage of t k time intervals contained in time interval T l, that are deemed to have Acceptable Performance. Acceptable Performance for a short time interval, t k, is based on a combination of three frame delivery characteristics (Composite One-way Frame Delay, Composite One-way Frame Delay Variation and Composite One-way Frame Loss). Composite One-way Frame Delay Variation is the difference in delay for Service Frames sent one right after the other. (The precise definition is presented in the following paragraphs.) The combination of three frame delivery characteristics for the short time interval, t k, is denoted as the Composite Performance Indicator, D i,j Tl ( t k ), which is defined in following paragraphs. An example of the use of the One-way Composite Performance Metric for clock synchronization is presented in Appendix E. Informally, the One-way Composite Performance Metric is based on Composite Performance Indicator values during a sequence of consecutive short time intervals. When the previous sequence was defined as Acceptable, if the Composite Performance Indicator exceeds its pre-set threshold for each short time interval in the current sequence, then the short time interval at the beginning of the current sequence is defined as Unacceptable; otherwise it is defined as Acceptable. On the other hand, when the previous sequence was defined as Unacceptable, if the Composite Performance Indicator is within its threshold for each short time interval in the current sequence, then the short time interval at the beginning of the current sequence is defined as Acceptable; otherwise, it is defined as Unacceptable. The formal definition follows. The following parameters are specific to the definition of the One-way Composite Performance Metric: Page 54

65 U in (0,1), the Composite Performance Indicator threshold which if exceeded suggests an unacceptable time interval. W fl = 0 or 1, the indicator for Composite One-way Frame Loss. W fd = 0 or 1, the indicator for Composite One-way Frame Delay. W fdv = 0 or 1, the indicator for Composite One-way Frame Delay Variation. DL > 0, the Composite One-way Frame Delay threshold in time units. Jt > 0, the Composite One-way Frame Delay Variation threshold in time units For a given i, j S and a given CoS_Name, t k is defined to be either Acceptable or Unacceptable. This is represented by AC i,j Tl ( t k ) where AC i,j Tl ( t k ) = 1 means that t k is Acceptable and AC i,j Tl ( t k ) = 0 means that t k is Unacceptable. AC i,j Tl ( t k ) is based on the Composite Performance Indicator, D i,j Tl ( t k ), over a number of consecutive short time intervals. For a given i, j S, a given CoS_Name, and a given T l, the Composite Performance Indicator, i,j ( t k ), is based on the frame delivery characteristics of ingress Qualified Service Frames 26 D Tl (Section ) mapped to the EVC EP i at the ingress UNI where EVC EP i is located that should be delivered to the egress UNI where EVC EP j is located according to the EVC Data Service Frame Disposition Service Attribute (Section 9.5), during the short time interval, t k. The short time interval, t k, is considered as an unacceptable interval if D i,j Tl ( t k ) > U. k For a given i, j S, a given CoS_Name, and a given T l let M Tl be the number of ingress Qualified Service Frames that are mapped to EVC EP i and arrive at the UNI during t k. Let these ingress Qualified Service Frames be numbered 1,2,, M k Tl, where Qualified Service Frame p arrived at the ingress UNI before Qualified Service Frame q if and only if p < q. Note that by the definition of Qualified Service Frames (Section ), for a given T l, ingress i,j Qualified Service Frames can only occur during a t k AT Tl which means that tk is con- i,j tained in T l. Thus if t k AT Tl, then k MTl = 0. ke Let M Tl be the number of unique (not duplicate) egress Service Frames where each Service Frame is the first unerrored egress Service Frame at the UNI where EVC EP j is located that results from a frame counted in M k Tl. A frame is considered lost if the ingress Qualified Service Frame does not result in an egress frame at the UNI where EVC EP j is located. Let m {1,2,, M k Tl } and M k Tl > 0. Then the Frame Loss Characteristic, fl i,j Tl,k(m), is defined as 26 The Class of Service Name used in the definition of Qualified Service Frames is the CoS_Name used in the CN 5- tuple in which the Performance Metric resides. Page 55

66 i,j (m) 1 if frame m is lost = { 0 if frame m is not lost fl Tl,k Let d i,j Tl,k(m) equal the One-way Frame Delay for frame m. Then the Frame Delay Characteristic, fd i,j Tl,k(m), is defined as fd i,j Tl,k(m) = { 1 if fl i,j T l,k(m) 1 and d i,j Tl,k(m) > DL 0 otherwise When both frame m and frame m 1 are not lost, let dv i,j Tl,k(m) = d i,j Tl,k(m) d i,j Tl,k(m 1) for m > 1. Then the Frame Delay Variation Characteristic, fdv i,j Tl,k(m), is defined as fdv i,j Tl,k(m) 1 if fl i,j = { Tl,k(m) 1 and fl i,j Tl,k(m 1) 1 and dv i,j Tl,k(m) > Jt and m > 1 0 otherwise Note that the above characteristics are undefined when M k Tl = 0. The Composite Performance Indicator, D i,j Tl ( t k ), is a ratio of the number of characteristics with value of 1 to the number of all characteristics during the short time interval, t k. For k m = 2,, M Tl let v i,j Tl,k(m) = { 1 if fl i,j T l,k(m) 1 and fl i,j Tl,k(m 1) 1 0 otherwise 1382 and let R i,j Tl ( t k ) = k M Tl m=1 W fl M k Tl (W fl fl i,j Tl,k(m) + W fd fd i,j Tl,k(m) + W fdv fdv i,j Tl,k(m)) Mk Tl i,j (m) Mk Tl + W fd (M k Tl fl m=1 Tl,k ) + W fdv v m=2 Tl,k i,j (m) 1383 then D i,j Tl ( t k ) is defined as D i,j Tl ( t k ) 0 if M k Tl = 0 = { 1 if (W fl = 0 and M ke Tl = 0 and M Tl R i,j Tl ( t k ) otherwise k M Tl k > 0) or (W fl = W fd = 0 and v i,j (m) = 0) m=2 Page 56

67 Note that at least one of W fl, W fd, or W fdv needs to be 1 for D i,j Tl ( t k ) to be well defined when k > 0. M Tl [R44] At least one of W fl, W fd, and W fdv MUST equal 1. i,j Recall that if t k AT Tl, then k MTl = 0. Consequently if t k is not contained T l or straddles the boundary of T l, then D i,j Tl ( t k ) = 0. Recall that t 0 is the first small time interval after the EVC is turned up (Section ). Then i,j ( t k ) is defined by the flowchart in Figure 20 for k = 0,1,. AC Tl Begin No AC Tl i,j t k 1 = 1 or k = 0 Yes /*Check acceptable status of previous interval*/ i,j D Tl t q U, q = k, k + 1,, k + n 1 Yes No i,j D Tl t q > U, q = k, k + 1,, k + n 1 No Yes 1391 /*Transition to acceptable if next n intervals have low Composite Performance Indicator value*/ AC Tl i,j AC Tl i,j t k = 1 t k = 0 /*Transition to unacceptable if next n intervals have high Composite Performance Indicator value*/ 1392 Figure 20 Flowchart Definition of AC i,j Tl ( t k ) Recall that { t k, k = 0,1, } and n can be different for different Class of Service Names. The Acceptable status for t k is based on the Composite Performance Indicator during t k and each of the following n 1 short time intervals and the Acceptable status of the previous short time interval. In other words, a sliding window of width n t is used to determine the One-way Composite Performance Metric. This use of a sliding window is similar to that of ITU-T Y.1563 [8]. Figure 21 presents an example of the determination of the Acceptable status for the short time intervals with a sliding window of 10 short time intervals where it assumed that all small time intervals belong to AT i,j Tl (Section ). Page 57

68 t z nt nt i, j k 1 i, j i, j AC 0 AC 1 l T t k T t k AC T t l l Time n 10 D i, j T l t U k D i, j T l t U k Figure 21 Example of the Determination of AC i,j Tl ( t k ) For a given i, j S, a given CoS_Name, and a given T l, the One-way Composite Performance is defined by 100 i,j AC Tl = { W Tl t k W Tl 100 otherwise AC i,j Tl ( t k ) if W Tl > where W Tl is defined in Section [R45] The SLS MUST define the One-way Composite Performance Metric as: AC Tl S i,j = min {AC Tl i, j S} Table 15 shows what is contained in a PM entry for the One-way Composite Performance Metric. Item Value Performance Metric Name One-way Composite Performance Metric S Non-empty subset of ordered EVC EP pairs U A real number in the range (0,1) DL A positive real number Jt A positive real number W fl An integer = 0 or 1 W fd An integer = 0 or 1 W fdv An integer = 0 or 1 AC Performance Metric Objective expressed as a percentage Table 15 PM Entry for the One-way Composite Performance Metric Page 58

69 [R46] The SLS MUST define the One-way Composite Performance Metric Objective as met over T l for a PM entry of the form in Table 15 if and only if AC TS AC One-way Group Availability Performance Metric The One-way Group Availability Performance Metric characterizes the percentage of time that at least a specified number of sets of ordered EVC EP Pairs are available. It is defined for a collection of two or more non-empty sets of ordered pairs of EVC EPs that are associated by the EVC denoted by G = {S 1,, S m }. Note that the Multiple EVC Service Level Specification Service Attribute (Section 12) contains a Performance Metric similar to the One-way Group Availability Performance Metric but is based on multiple EVCs. The following parameters are specific to the definition of the One-way Group Availability Performance Metric: G = {S 1,, S m }, where each element in G is a non-empty set of ordered pairs of EVC EPs, and K, an integer 1. For a given CoS_Name 27 and a given G, define A g ( t k, S) for S G as A g ( t k, S) = min{a i,j ( t k ) i, j S} where A i,j ( t k ) is defined in Section Note that A g ( t k, S) = 1 when all ordered EVC EP pairs in S have been experiencing low loss. Otherwise, A g ( t k, S) = 0. The One-way Group Availability for the time interval t k is defined as 1431 [R47] A G ( t k ) = { 1 if Ag ( t k, S) K S G 0 otherwise The SLS MUST define the One-way Group Availability Performance Metric as 100 A G G ( t k ) if W Tl > 0 = { W Tl t k W Tl 100 otherwise A Tl 1432 Note that W Tl is defined in Section The Class of Service Name used is the CoS_Name used in the CN 5-tuple in which the Performance Metric resides. Page 59

70 The One-way Group Availability Performance Metric can be viewed as the percentage of time that at least K S k s in G are Available. Table 16 shows what is contained in a PM entry for the One-way Group Availability Performance Metric. Item Value Performance Metric Name One-way Group Availability Performance Metric G = {S 1,, S m } Non-empty subsets of ordered EVC EP pairs K A integer 1 A G Performance Metric Objective expressed as percentage Table 16 PM Entry for the One-way Group Availability Performance Metric [R48] The SLS MUST define the One-way Group Availability Performance Metric Objective as met over T l for a PM entry of the form in Table 16 if and only if G A G. A Tl EVC Group Membership Service Attribute The value of the EVC Group Membership Service Availability is Not Applicable or a list of 3- tuples of the form MEGAOID, CoS_Name g, S g where: MEGAOID is a string that is one of the values in an instance of the Multiple EVC Service Level Specification Service Attribute (Section 12). CoS_Name g is an entry in the value of the EVC List of Class of Service Names Service Attribute (Section 9.9) that is not Discard. S g is a subset of ordered EVC EP pairs constructed from the value of the EVC EP List Service Attribute (Section 9.3) [R49] When the value of the EVC Group Membership Service Attribute is a list of 3- tuples, any pair of 3-tuples with the same value of MEGAOID MUST have different values for at least one of CoS_Name g and S g. When the value is Not Applicable, the EVC is not used as part of an instance of the Multiple EVC Service Level Specification Service Attribute (Section 12). The EVC can be used in more than one instance of the Multiple EVC Service Level Specification Service Attribute (Section 12) by having more than one value of MEGAOID in the list or 3-tuples. Note that Section 12 constrains the values of the EVC Service Level Specification Service Attribute for all 3-tuples with the same value of MEGAOID EVC Maximum Service Frame Size Service Attribute The value of the EVC Maximum Service Frame Size Service Attribute is an integer 1 in bytes. Any ingress C-Tagged Service Frame whose length exceeds the value of the Maximum Service Page 60

71 Frame Size Service Attribute is likely to be discarded. Any ingress Untagged Service Frame whose length exceeds the value of the Maximum Service Frame Size Service Attribute minus 4 is likely to be discarded [R50] [R51] [D1] [D2] The value of the EVC Maximum Service Frame Size Service Attribute MUST be at least 1522 bytes. The value of the EVC Maximum Service Frame Size Service Attribute MUST be less than or equal to the value of the Subscriber UNI Maximum Service Frame Size Service Attribute (Section 10.8) for all UNIs in the EVC. An ingress C-Tagged Service Frame that is mapped to an EVC EP that is in the EVC and whose length exceeds the value of the EVC Maximum Service Frame Size Service Attribute SHOULD be discarded. An ingress Untagged Service Frame that is mapped to an EVC EP that is in the EVC and whose length exceeds the value of the EVC Maximum Service Frame Size Service Attribute minus 4 SHOULD be discarded EVC Available MEG Level Service Attribute The value of the EVC Available MEG Level Service Attribute is an integer from 0 to 7 or None. The value of EVC Available MEG Level Service Attribute is the MEG Level that is one MEG Level higher than any MEG level reserved by the Service Provider for MEGs whose MEPs are contained entirely within the Service Provider s CEN. The value None indicates that SOAM Service Frames at any MEG Level might or might not pass over this EVC. If an integer value is specified, then SOAM Service Frames at or above that MEG Level that not consumed by a MIP in the CEN are Data Service Frames (Section 8.5.3). Note that the Service Provider can instantiate MEPs or MIPs at or above the value of the EVC Available MEG Level on UNIs that bound the EVC, if requested by the Subscriber. Page 61

72 Subscriber UNI Service Attributes This section describes attributes at each UNI. A UNI can have a number of characteristics that will be important to the way that the SE sees a service. One of the key aspects of a service description will be the allowable mix of different characteristics for the UNIs in the EVC. For example, a specific (simple) service might require all UNIs to have the same UNI Line Rate at the physical layer. A more sophisticated service may allow a wide variety of UNI Line Rates Subscriber UNI ID Service Attribute 28 The value of the Subscriber UNI ID Service Attribute is a string that is used to allow the Subscriber and Service Provider to uniquely identify the UNI for operations purposes [R52] [R53] [R54] The value of the Subscriber UNI ID Service Attribute MUST be unique among all UNIs for the CEN. The value of the Subscriber UNI ID Service Attribute MUST contain no more than 45 characters. 7 The value of the Subscriber UNI ID Service Attribute MUST be a non-null RFC 2579 [12] DisplayString but not contain the characters 0x00 through 0x1f As an example, the Subscriber and Service Provider might agree to use SCPOP1-Node3-Slot2- Port1" as a value of the Subscriber UNI ID Service Attribute and this could signify Port 1 in Slot 2 of Node 3 in Santa Clara POP1. Note that [R52] does allow two Service Providers to use the same identifier for different UNIs (one UNI per Service Provider). Of course, using globally unique identifiers for UNIs meets [R52] Subscriber UNI Instantiation Service Attribute The value of the Subscriber UNI Instantiation Service Attribute is either Physical or Virtual. When the value is Physical, the UNI is implemented using one or more instances of an IEEE Std [4] Physical Layer (Section 10.4). When the value is Virtual, the physical layer is not specified. Figure 22 shows an example where Subscriber and Service Provider UNI-related functions are implemented in two different Virtual Machines inside a Server. The UNI lies between the two Virtual Machines. The connection from the Server to the rest of the Subscriber s network (to the left) and the connection from the Server to the rest of the Service Provider CEN are beyond the scope of this document. 28 In MEF 10.3 [18] this Service Attribute is called UNI ID Service Attribute. Page 62

73 UNI Service Provider CEN Subscriber Functions Virtual Machine SP Functions Virtual Machine Server Figure 22 Example of the Subscriber UNI Instantiation Service Attribute = Virtual When the value of the Subscriber UNI Instantiation Service Attribute = Virtual, the information passed across the UNI is called a Virtual Frame. In the case of Figure 22, examples of the Virtual Frame include: A pointer to a common memory location that contains information relevant to the Ethernet Service, and A block of bits transferred over a backplane The details of the Virtual Frame are beyond the scope of this document but the following requirements apply [R55] [R56] When the value of the Subscriber UNI Instantiation Service Attribute = Virtual, there MUST exist a map that maps the set of all possible sequences of Virtual Frames to the set of sequences of pairs of the form s, t where s is a standard Ethernet frame per Clause 3 of IEEE Std [4] and t is the arrival time to be used for this Service Frame when the frame is in a Bandwidth Profile Flow (Section 13). When the value of the Subscriber UNI Instantiation Service Attribute = Virtual, if the result of applying the map referred to in [R55] is { s k, t k, k = 0,1,2,. }, then the following MUST hold: t k+1 t k, k = 0,1,2, In other words, applying the map of [R55] to a sequence of Virtual Frames yields a corresponding sequence of IEEE Std [4] Ethernet frames, each with an associated arrival time. Page 63

74 Subscriber UNI Virtual Frame Map Service Attribute The value of the Subscriber UNI Virtual Frame Map Service Attribute is either a map that meets [R55] and [R56] or Not Applicable [R57] [R58] When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical, the value of the Subscriber UNI Virtual Frame Map Service Attribute MUST be Not Applicable. When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual, the value of the Subscriber UNI Virtual Frame Map Service Attribute MUST be a map that meets [R55] When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical, the Service Frame for the UNI is defined as the first bit of the Destination Address through the last bit of the Frame Check Sequence of the IEEE Std [4] Ethernet frame that passes over an IEEE Std [4] Physical Layer. When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual, the Service Frame is defined as the first bit of the Destination Address through the last bit of the Frame Check Sequence of the IEEE Std [4] Ethernet frame that results from applying value of the Subscriber UNI Virtual Frame Map Service Attribute. The details of possible values of the Subscriber UNI Virtual Frame Map Service Attribute are beyond the scope of this document but, like all Service Attribute values, need to be agreed to by the Subscriber and Service Provider Subscriber UNI List of Physical Links Service Attribute Editor Note 8: Editor Note 9: We have identifiers for the UNI and for the EVC which allows the Subscriber and Service Provider to unambiguously refer to a specific instance. Should we introduce a physical link identifier for the same purpose when there are multiple physical links? To do this we could make the value of this Service Attribute a 4-tuple of the form id, pl, fs, ts where id is the identifier for the physical link. If a 4-tuple is better, then a 5-tuple should be even more valuable. How about a 5-tuple of the form seq, id, pl, fs, ts where seq is a sequence number starting at 1. This sequence number would be used in the value of the Subscriber UNI Port Conversation to Aggregation Link Map Service Attribute The value of the Subscriber UNI List of Physical Links Service Attribute is either a list of 3- tuples of the form pl, fs, ts or Not Applicable. The value of pl specifies a physical layer, the value of fs is either Enabled or Disabled, and the value of ts is either Enabled or Disabled [R59] When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical, the value of the Subscriber UNI List of Physical Links MUST 29 In MEF 10.3 [18] this Service Attribute is called Physical Layer Service Attribute. Page 64

75 [R60] [R61] [R62] be a list of 3-tuples of the form pl, fs, ts with one 3-tuple for each physical link implementing the UNI. When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical, value of pl in each pl, fs, ts 3-tuple MUST be one of the PHYs listed in IEEE Std [4] but excluding 1000BASE-PX-D and 1000BASE-PX-U. When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical, the Physical Layer specified by each value of pl MUST operate in full duplex mode. When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual, the value of the Subscriber UNI List of Physical Links Service Attribute MUST be Not Applicable Note that when the Subscriber UNI Instantiation Service Attribute = Physical, different physical links implementing the UNI can use different physical layers. When the value of fs in a 3-tuple is Enabled, synchronous Ethernet is used on the physical link corresponding to the 3-tuple [R63] When the value of fs = Enabled in a 3-tuple in the value of Subscriber UNI List of Physical Service Attribute, synchronous Ethernet as defined in ITU-T G.8262/Y.1362 [6] and ITU-T G.8264/Y.1364 [7] MUST be used on the corresponding physical link The accuracy of the frequency reference provided on a physical link with fs = Enabled is beyond the scope of this document. The peering of L2CP frames carrying messages for the Ethernet Synchronization Message Channel (ESMC) as specified in ITU-T G [6] is beyond the scope of this document. MEF 22.2 [24] contains an example of the use of ESMC [R64] When the value of ts in a 3-tuple in the value of the Subscriber UNI List of Physical Links Service Attribute is Enabled, the Precision Time Protocol as specified in IEEE [5] MUST be used on the corresponding physical link such that the CE can derive a Primary Reference Time Clock traceable time synchronization reference from the CEN Editor Note 10: It possible to run one instance of PTP over a Link Aggregation Group. This configuration is not covered in the current text. Comments are solicited regarding the desirability of adding PTP over LAG as another possible configuration. The accuracy of the time reference provided on a physical link with ts = Enabled is beyond the scope of this document. Page 65

76 When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical, a UNI may contain one or more physical links. When multiple physical links are configured at a UNI, the individual links may terminate at the same device in the CEN and/or in the SE, or at different devices in the CEN and/or in the SE. The configuration for the termination of the physical link or links that implement the UNI is beyond the scope of this document. When the value of the Subscriber UNI List of Physical Links Service Attribute is a list of 3- tuples with more than one 3-tuple in the list, a resiliency mechanism is required and is identified by the Subscriber UNI Link Aggregation Service Attribute specified in Section Subscriber UNI Link Aggregation Service Attribute 30 The value of the Subscriber UNI Link Aggregation Service Attribute value is one of None, 2- Link Active/Standby, All Active, Other, or Not Applicable. The value of this Service Attribute is dependent on the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) and the value of the Subscriber UNI List of Physical Links Service Attribute (Section 10.4). See Appendix F for some configuration examples for multiple physical links [R65] [R66] [R67] If the value of the Subscriber UNI List of Physical Links Service Attribute (Section 10.4) = a list of a single 3-tuple, then the value of the Subscriber UNI Link Aggregation Service Attribute MUST be set to None. If the value of the Subscriber UNI List of Physical Links Service Attribute (Section 10.4) = a list of two 3-tuples, then the value of the Subscriber UNI Link Aggregation Service Attribute MUST be set to one of 2-Link Active/Standby, All Active, or Other. If the value of the Subscriber UNI List of Physical Links Service Attribute (Section 10.4) = a list of three or more 3-tuples, then the value of the Subscriber UNI Link Aggregation Service Attribute MUST be set to either All Active or Other Note that [R65], [R66], and [R67] only apply when the value of the Subscriber Instantiation Service Attribute = Physical. Table 17 summarizes the above requirements. Number of 3-tuples* None Active/Standby All Active Other or more * Applies when the value of the Subscriber UNI Instantiation Service Attribute = Physical Table 17 Allowed Values of the Subscriber UNI Link Aggregation Service Attribute [R68] When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual, the value of the Subscriber UNI Link Aggregation Service Attribute MUST be Not Applicable. 30 In MEF 10.3 [18] this is called UNI Resiliency Service Attribute. Page 66

77 The following requirements depend on the value of the Subscriber UNI Link Aggregation Service Attribute. [R69] When the value of the Subscriber UNI Link Aggregation Service Attribute = 2- Link Active/Standby, the CEN MUST implement Link Aggregation as in either Clause of IEEE Std 802.1AX 2008 [1] or Clause of IEEE Std 802.1AX 2014 [2] with one Link Aggregation Group (LAG) across the links supporting the UNI and with one link in active mode and the other in standby mode [R70] When the value of the Subscriber UNI Link Aggregation Service Attribute = All Active the CEN MUST use Link Aggregation as specified in Clause 5.3 of IEEE Std 802.1AX-2014 [2], including the use of the version 2 LACPDUs as specified in Clause 5.3.1h of IEEE Std 802.1AX-2014 [2], with one Link Aggregation Group (LAG) across the links supporting the UNI [R71] When the value of the Subscriber UNI Link Aggregation Service Attribute = All-Active, the CEN MUST use Per-service frame distribution as specified in Clause 8.2 of IEEE Std 802.1AX-2014 [2], where the Port Conversation ID is equal to the VLAN ID for VLAN Tagged Service Frames and equal to 0 for Untagged Service Frames and Priority Tagged Service Frames. [R71] means that the Service ID for each Service Frame is the value of the VLAN ID in the C- Tag when present and is 0 when the Service Fame has no C-Tag. [R71] also means that the Port Conversation ID = Service ID in the Service ID to Port Conversation ID Map. [R72] When the value of the Subscriber UNI Link Aggregation Service Attribute = All-Active, the CEN MUST be configured such that there is only one aaggactoradminkey that has the same value as the aaggportactoradminkey for the ports terminating the links at the UNI. The aaggactoradminkey and aaggportactoradminkey are managed objects defined in IEEE Std 802.1AX-2014 [2]. Ensuring that there is only one aaggactoradminkey with the same value as the aaggportactoradminkey for the ports terminating the links at the UNI assures that only a single Link Aggregation Group is formed at the UNI. This eliminates that possibility of any loops potentially arising from multiple UNI links coming up independently or forming separate Link Aggregation Groups [O3] The Subscriber and the Service Provider MAY implement any other resiliency mechanism when the value of the Subscriber UNI Link Aggregation Service Attribute = Other The other resiliency mechanism referred to in [O3] is beyond the scope of this document. Page 67

78 Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute The value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute is either a Port Conversation ID to Aggregation Link Map as defined in IEEE Std 802.1AX 2014 [2] or Not Applicable [R73] [R74] The value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute MUST be Not Applicable when the value of the Subscriber UNI Link Aggregation Service Attribute (Section 10.5) does not equal All Active. When the value of the Subscriber UNI Link Aggregation Service Attribute (Section 10.5) = All Active, the value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute MUST be a Port Conversation ID to Aggregation Link Map as defined in IEEE Std 802.1AX 2014 [2] The Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute value is the mapping of each Port Conversation ID (see [R71]) to a Link Selection Priority List at the UNI. The Link Selection Priority List is a sequence of Link Number IDs, in the order of usage preference, highest to lowest, for the link that is to carry the Service Frames corresponding to that Port Conversation ID. The value of a Link Number ID has local significance to the LAG at a given UNI [R75] When the value of the Subscriber UNI Link Aggregation Service Attribute (Section 10.5) = All Active, the set of Link Number IDs as defined in IEEE Std 802.1AX 2014 [2] at the UNI MUST be {1,2,, m} where m is the number of 3-tuples in the value of the Subscriber UNI List of Physical Links Service Attribute (Section 10.4) [R75] mandates the value of Link Number IDs that are used in the value of the Subscribe UNI Port Conversation ID to Aggregation Link Map Service Attribute; this avoids the need to negotiate the values between the Service Provider and Subscriber for a given UNI. The Service Provider and Subscriber do not need to agree on an association of each Link Number ID to a physical link (or the physical port terminating the link) as this association is made during the operation of LACP. The Service Provider and Subscriber can agree on an association of each Link Number ID to a physical link, which could be useful if there is a preference for which physical link carries specific Service Frames in the absence of any link failures. The Port Conversation ID to Aggregation Link Map Service Attribute is required when the UNI Resiliency Service Attribute is set to All-Active and can be used when the UNI Resiliency Service Attribute is set to Other. However the use of the Port Conversation ID to Aggregation Link Map Service Attribute for the latter case is beyond the scope of this document. Note that the Port Conversation ID to Aggregation Link Map Service Attribute is equivalent to the aaggconversationadminlink[] that is defined in Clause of IEEE Std 802.1AX-2014 [2]. Page 68

79 The distribution of Service Frames across the different physical links at a given UNI is based on the agreed values in the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute. If the first link in the Link Selection Priority List for a given Port Conversation ID is operationally available in the LAG, all of the Service Frames with the corresponding Port Conversation ID are carried on that link in both directions. If the first link fails, then the second link in the list is used if the second link is operational, and so on. If all links in the list fail, the Service Frames with the corresponding Port Conversation ID are not carried over the UNI in either direction, i.e., they are dropped, even if a link that is not in the list is still operational. The number of links in a Link Selection Priority List in the value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute is, by definition, less than or equal to the number of physical links for that UNI. A shorter list results in lower resilience for the Service Frames corresponding to the Port Conversation ID. Note that a Port Conversation ID may have an empty Link Selection Priority List in the value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute, in which case Service Frames with the corresponding Port Conversation ID are not carried across the UNI. If a particular Link Number ID is in a Link Selection Priority List in the value of the Subscriber UNI Port Conversation ID to Link Aggregation Map Service Attribute, but not the first link in any list in the attribute, then the physical link associated with that Link Number ID does not carry any Service Frames if all other links at the UNI are operational. In this case, the link can be considered as a backup link that is reserved for protection against failure of another link. Table 18 illustrates an example of a value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute that contains three physical links with three Link Number IDs, 1, 2, and 3. In this example, six Port Conversation IDs have a non-empty Link Selection Priority List while other Port Conversation IDs have an empty Link Selection Priority List at the UNI. As shown in Table 18, the Link Selection Priority List for Port Conversation IDs 0, 1, and 4 contains Link Number IDs 1, 3, and 2 in the sequence. The Link Selection Priority List for Port Conversation ID 5 has 2, 3, and 1; the list for Port Conversation ID 10 has 2, 1, and 3; the list for Port Conversation ID 1000 has 2 and 1. In this example, link 3 is not used when both link 1 and 2 are operational. Thus link 3 is used for protection purposes. The example also indicates that the Service Frames corresponding to Port Conversation IDs 5 and 10 are carried over link 2 when link 2 is operational; when link 2 fails and link 1 and 3 are operational, the Service Frames with Port Conversation ID 5 are carried over link 3 and the Service Frames with Port Conversation ID 10 are carried over link 1. The Service Frames with Port Conversation ID 1000 in the example have less resilience than the Service Frames corresponding to Port Conversation IDs 0, 1, 4, 5, and 10. Page 69

80 Port Conversation ID Link Selection Priority List (decreasing order) 0, 1, 4 1, 3, 2 5 2, 3, , 1, , 1 All other values Table 18 Example of a Value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute for a UNI Note that the Table 18 is an abstract description for the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute. This description does not constrain how the contents can be described in a protocol, database, service order form, etc. The value in the Port Conversion ID to Aggregation Link Map Service Attribute is only used for Service Frame distribution at a given UNI. Which EVC EP a Service Frame is mapped to at the UNI is determined by the value EVC EP Map Service Attribute (Section 11.4). The Subscriber UNI Service Attributes are normally configured to ensure that, for every CE-VLAN ID that is mapped to an EVC, the corresponding Port Conversation ID maps to a non-empty Link Selection Priority List in the Port Conversation ID to Aggregation Link Map Service Attribute [O4] When the value of the Subscriber UNI Link Aggregation Service Attribute (Section 10.5) = All Active and the value of the EVC EP Map Service Attribute (Section 11.4) maps more than one CE-VLAN ID value to an EVC EP, the CEN MAY support a value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute such that Service Frames with different CE- VLAN ID values mapped to the EVC EP can be carried on different physical links The value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute described in [O4] is useful when the bandwidth needed for the EVC EP exceeds the capacity of a single physical link at the UNI. However, in certain configurations (for example when the links terminate on different devices in the CEN), supporting such map could require a Service Provider to make tradeoffs between the Service Frame distribution and the application of MEF SOAM and Bandwidth Profiles [R76] When the value of the Subscriber UNI Link Aggregation Service Attribute (Section 10.5) = All Active and Ingress Bandwidth Profiles and/or Egress Bandwidth Profiles are used at the UNI, the Service Provider MUST be able to provide a value in the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute such that all Service Frames that map to a given Envelope (Section 13) are carried on the same physical link. Page 70

81 Note that when Service Frames that map to a given Envelope are carried on different links, it may be difficult to apply the Bandwidth Profile algorithm in the Service Provider CEN, and it may be difficult for the Subscriber to apply shaping in the SE, especially if the different links happen to terminate on different devices. The Service Provider can offer a value in the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute where Service Frames that map to a given Envelope are carried on different links, if they have the capability to apply the Bandwidth Profile algorithm to such frames (or if there is no Bandwidth Profile configured at the UNI). However, [R76] requires the Service Provider to also support a map where Service Frames that map to a given Envelope are carried on a single link. Appendix G contains information on how Service Frames are distributed across multiple links at the UNI based on the value of the Subscriber UNI Port Conversation ID to Aggregation Link Map Service Attribute Subscriber UNI Service Frame Format Service Attribute 31 The value of the Subscriber UNI Service Frame Format Service Attribute is Ethernet MAC Frame conforming to Clause 3 of IEEE Std [R77] The format of the Service Frame MUST be that of the MAC frame that is specified in Clause 3 of IEEE Std [4] [R77] is a requirement on the value of the Subscriber UNI Virtual Frame Map when the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual. This is because the Service Frame is the result of applying the value of the Subscriber UNI Virtual Frame Map (Section 0) to the Virtual Frame when value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual. Note that [R77] means that Service Frames will be discarded by the receiving Service Provider CEN if they are not properly constructed. For example, a Service Frame with an incorrect Frame Check Sequence will be discarded. However, this document provides for Service Frames that are longer than the maximum specified in IEEE Std [4]. See Section Subscriber UNI Maximum Service Frame Size Service Attribute 32 The value for the Subscriber UNI Maximum Service Frame Size Service Attribute is an integer 1 in bytes [R78] The value of the Subscriber UNI Maximum Service Frame Size Service Attribute MUST be at least 1522 bytes Note that the value of the Subscriber UNI Maximum Service Frame Size Service Attribute constrains the value of the EVC Maximum Service Frame Size Service Attribute via [R51]. 31 In MEF 10.3 [18] this Service Attribute is called Service Frame Format Service Attribute. 32 In MEF 10.3 [18] this Service Attribute is called UNI Maximum Service Frame Size Service Attribute. Page 71

82 Subscriber UNI Maximum Number of EVC EPs Service Attribute 33 The value of the Subscriber UNI Maximum Number of EVC EPs Service Attribute is an integer 1 that specifies the maximum number of EVC EPs that can be located at the UNI. Editor Note 11: Per the 2Q2017 quarterly meeting, the Service Multiplexing Service Attribute is removed and a new term, Service Multiplexing is introduced via the following text. Figure 23 shows an example of the value of the Subscriber UNI Maximum Number of EVC EPs Service Attribute. In this example, the value of the Subscriber UNI Maximum Number of EVC EPs = 7 at UNI A, 3 at UNI B, 1 at UNI C, and 1 at UNI D. The number of EVC EPs located at UNI A can be as many as 7 but in this example it is only 3. Similarly the number of EVC EPs located on UNI B is less than the maximum number. UNI B (3) Service Provider CEN UNI A (7) UNI C (1) UNI D (1) UNI EVC End Point EVC (x) Value of the Subscriber UNI Maximum Number EVC EPs Service Attribute Figure 23 Example of the Subscriber UNI Maximum Number of EVC EPs Service Attribute For ease of description of configurations like that in Figure 23, the term Service Multiplexing is introduced. There are two definitions for Service Multiplexing: Definition 1: The condition when there is more than one EVC End Point located at a UNI. In Figure 23, UNI A has Service Multiplexing. 33 In MEF 10.3 [18] this is called Maximum Number of EVCs Service Attribute. Page 72

83 Definition 2: The capability of the Service Provider CEN to locate more than one EVC End Point at a UNI. In Figure 23 UNI A and UNI B are capable of Service Multiplexing Subscriber UNI Maximum Number of CE-VLAN IDs per EVC EP Service Attribute The value of the Subscriber UNI Maximum Number of CE-VLAN IDs per EVC EP Service Attribute is an integer 1 that specifies the largest number of CE-VLAN ID values that can map to an EVC EP in a EVC EP Map Service Attribute (Section 11.4) at the UNI. Note that when more than one CE-VLAN ID value is mapped to an EVC EP at a UNI, [R22] mandates that the EVC that associates the EVC EP have the value of the EVC CE-VLAN ID Preservation Service Attribute = Enabled. This document does not constrain the way that the Service Provider and Subscriber communicate the value of the EVC EP Map Service Attribute. For example, a Subscriber and a Service Provider could agree to describe Bundling as shown in Figure 24. Note that the value of the EVC EP Map Service Attribute shown in 11.4 can only occur when the value of the Subscriber UNI Maximum Number of CE-VLAN IDs per EVC EP Service Attribute is greater than or equal to Description Actual Value 1 2 All but 0, 2000, and Figure 24 Example of a Simple Description of the EVC EP Map Service Attribute Value For ease of description of maps like that in Figure 24, the term Bundling is introduced. There are two definitions for Bundling: Definition 1: The condition when there is more than one CE-VLAN ID value mapped to an EVC EP at a UNI. Definition 2: The capability of the Service Provider CEN to map more than one CE-VLAN ID value to an EVC EP at a UNI. Page 73

84 Subscriber UNI All to One Bundling Service Attribute 34 The value of the Subscriber UNI All to One Bundling Service Attribute is either Enabled or Disabled. [R79] When the value of the Subscriber UNI All to One Bundling Service Attribute = Enabled, there MUST be exactly one EVC EP located at the UNI. [R80] When the value of the Subscriber UNI All to One Bundling Service Attribute = Enabled, all CE-VLAN IDs values MUST map to the single EVC EP at the UNI via the value of the EVC EP Map Service Attribute. [R81] When the value of the Subscriber UNI All to One Bundling Service Attribute = Enabled, all other UNIs in the EVC associating the EVC EP at this UNI MUST have the value of the Subscriber UNI All to One Bundling Service Attribute = Enabled. Note that [R22] means that the EVC that associates the single EVC EP at the UNI with the value of the Subscriber UNI All to One Bundling Service Attribute = Enabled is required to have the value of the EVC CE-VLAN ID Preservation Service Attribute = Enabled Subscriber UNI Token Share Service Attribute The value of the Subscriber UNI Token Share Service Attribute is either Enabled or Disabled [R82] [D3] [R83] When the value of the Subscriber UNI Token Share Service Attribute = Enabled, the Service Provider MUST be able to provide at least one Envelope with two or more Bandwidth Profile Flows mapped to it. When the value of the Subscriber UNI Token Share Service Attribute = Enabled, the Service Provider SHOULD be able to map two or more Bandwidth Profile Flows to every Envelope. When the value of the Subscriber UNI Token Share Service Attribute = Disabled, every Envelope at the UNI MUST have exactly one Bandwidth Profile Flow mapped to it See Section 13 for the descriptions of Envelope and Bandwidth Profile Flow Subscriber UNI Envelopes Service Attribute The value of the Subscriber UNI Envelopes Service Attribute is a list of pairs of the form x, y where x is an Envelope ID value and y is the Envelope Coupling Flag (CF 0 ) value. 34 In MEF 10.3 [18] this is called All to One Bundling Service Attribute. Page 74

85 Table 19 shows the parameters for each pair. Note that the descriptions in the table are informal. The precise role played by a given parameter is determined by the Bandwidth Profile Algorithm (Section 13.2). Parameter Name Symbol Units Envelope ID RFC 2579 [12] DisplayString Envelope Coupling Flag Informal Description Identifies the Envelope CF 0 Integer Controls the conversion of unused Green tokens into Yellow tokens Table 19 Envelope Parameters [R84] The Envelope ID MUST contain no more than 45 characters [R85] [R86] The Envelope ID MUST be unique among all Envelope IDs at a UNI. The Envelope ID MUST be a non-null RFC 2579 [12] DisplayString but not contain the characters 0x00 through 0x1f [R87] CF 0 MUST have only one of two possible values, 0 or 1. [R88] When one Bandwidth Profile Flow (Section 13) is mapped to an Envelope, CF 0 MUST equal 0. Note that the concatenation of the UNI ID and the Envelope ID is unique among all Envelopes for the CEN [R89] [R90] The value of the Subscriber UNI Envelopes Service Attribute MUST contain at most one entry with a given Envelope ID value. The Envelope ID value in the Envelope and Rank Parameter (ER i ) for each Bandwidth Profile Flow (Section 13) specified at the UNI MUST match an Envelope ID value in an entry in the value of the Subscriber UNI Envelopes Service Attribute Subscriber UNI Ingress Bandwidth Profile Service Attribute 36 The value of the Subscriber UNI Ingress Bandwidth Profile Service Attribute is either Disabled or the 10-tuple CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F where each item in the 10-tuple is defined in Section [R91] When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual, the value of the Subscriber UNI Ingress Bandwidth Profile Service Attribute MUST be Disabled. 35 Note that [R5] of MEF 6.2 [15] conflicts with this requirement. 36 In MEF 10.3 [18] this is called Ingress Bandwidth Profile per UNI Service Attribute. Page 75

86 The Subscriber UNI Ingress Bandwidth Profile Service Attribute is intended to accommodate legacy equipment that is not capable of more fine grained and more useful Bandwidth Profiles. Consequently [R91] mandates that the Ingress Bandwidth Profile per UNI = Disabled when the UNI Instantiation = Virtual [R92] [R93] When the value of the Subscriber UNI Ingress Bandwidth Profile Service Attribute = CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F, the CEN MUST apply the Bandwidth Profile Algorithm (Section 13.2) using these parameter values to the Ingress UNI Bandwidth Profile Flow (Section 13). An ingress Service Frame that is declared Red by the application of the Bandwidth Profile Algorithm per [R92] MUST be discarded Note that if an ingress Service Frame is declared Green and it meets other conditions per the definition of Qualified Service Frame in Section , then the SLS applies to this Service Frame. Note that, per the definition of Qualified Service Frame in in Section , an ingress Service Frame that is declared Yellow is not subject to the Performance Metrics and associated Performance Metric Objectives of the SLS. The better the level of Bandwidth Profile compliance, the fewer Service Frames will be discarded. In order to improve the level of Bandwidth Profile compliance, a Subscriber may need to shape traffic in the SE (Appendix B contains a shaping example). Figure 25 illustrates an example of the application of the value of the Subscriber UNI Ingress Bandwidth Profile Service Attribute = CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F. In the example of Figure 25, ingress Service Frames mapped to the three EVC EPs would all be subject to a single Ingress Bandwidth Profile. The Subscriber UNI Ingress Bandwidth Profile manages bandwidth non-discriminately for all EVC EPs at the UNI, i.e., some EVC EPs may get more bandwidth while others may get less. Page 76

87 EP 1 UNI EP 2 Subscriber UNI Ingress Bandwidth Profile EP Figure 25 Subscriber UNI Ingress Bandwidth Profile Example Subscriber UNI Egress Bandwidth Profile Service Attribute 37 Editor Note 12: Is it desirable to simplify Egress Bandwidth Profile Service Attributes? For example, we could mandate that CM i = color-blind to ease the burden on the Service Provider. The value of the Subscriber UNI Egress Bandwidth Profile Service Attribute is either Disabled or the 10-tuple CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F where each item in the 10-tuple is defined in Section [R94] When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual, the value of the Subscriber UNI Egress Bandwidth Profile Service Attribute MUST be Disabled The Subscriber UNI Egress Bandwidth Profile Service Attribute is intended to accommodate legacy equipment that is not capable of more fine grained and more useful Bandwidth Profiles. Consequently [R94] mandates that the value of the Subscriber UNI Egress Bandwidth Profile Service Attribute = Disabled when the UNI Instantiation = Virtual [R95] When the value of the Subscriber UNI Egress Bandwidth Profile Service Attribute = CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F, the application of the Bandwidth Profile Algorithm (Section 13.2) using these parameter values to the Egress UNI Bandwidth Profile Flow (Section 13) MUST result in each egress Service Frame being declared Green or Yellow. 37 In MEF 10.3 [18] this is called Egress Bandwidth Profile per UNI Service Attribute. Page 77

88 The implication of [R95] is that the Subscriber will receive a sequence of egress Service Frames that conforms to the Bandwidth Profile with parameters CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F. In other words, the handling of the Service Frames in the CEN is such that all egress Service Frames that would be declared Red if the Subscriber applied the Bandwidth Profile Algorithm to the Bandwidth Profile Flow are discarded before reaching the egress UNI. It is important to reiterate that this description does not mandate or constrain in any way the implementation in the Service Provider CEN. Note that Service Frames discarded in order to meet [R95] can affect the One-way Frame Loss Ratio Performance Metric (Section ). Likewise Service Frames buffered in order to meet [R95] can affect one-way frame delay and delay variation. Therefore, the parameter values for the Subscriber UNI Egress Bandwidth Profile Service Attribute need to be set carefully so that meeting [R95] does not cause the Performance Metric objectives of the SLS to be missed. The Subscriber UNI Egress Bandwidth Profile Service Attribute manages bandwidth nondiscriminately for all EVC EPs at the egress UNI, i.e. some EVC EPs may get more bandwidth while others may get less. Figure 26 portrays an example of this model of Egress Bandwidth Profile Service Attribute. UNI i (ingress) UNI n (egress) Subscriber UNI Egress Bandwidth Profile UNI j (ingress) UNI k (ingress) to Other Egress UNIs EVC EP Figure 26 Subscriber UNI Egress Bandwidth Profile Example Page 78

89 Subscriber UNI Link OAM Service Attribute The value of the Subscriber UNI Link OAM Service Attribute is either Enabled or Disabled [R96] [R97] [R98] [D4] When the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual, the value of the Subscriber UNI Link OAM Service Attribute MUST be Disabled. When the value of the Subscriber UNI Link OAM Service Attribute = Enabled, Link OAM as specified in Clause 57 of IEEE Std [4] MUST be run on all physical links in the UNI. When the value of the Subscriber UNI Link OAM Service Attribute = Enabled, the CEN MUST enable Active DTE mode capabilities as specified in clause of IEEE Std [4] on each link in the UNI. When the value of the Subscriber UNI Link OAM Service Attribute = Enabled, Link Events as specified in Clauses and of IEEE Std [4] SHOULD be enabled on each link in the UNI Subscriber UNI MEG Service Attribute 38 The value of the Subscriber UNI MEG Service Attribute is either Enabled or Disabled [R99] When the value of the Subscriber UNI MEG Service Attribute = Enabled, the CEN MUST instantiate a UNI MEG MEP When the value of the Subscriber UNI MEG Service Attribute = Enabled, several parameter values need to be agreed upon by the Subscriber and the Service Provider. Further information can be found in MEF 30.1 [28]. Editor Note 13: When MAEL is complete, it may provide some guidance on setting values for parameters related to the UNI MEG. Check MAEL when it is complete Subscriber UNI L2CP Address Set Service Attribute The Subscriber UNI L2CP Address Set Service Attribute is the L2CP Address Set Service Attribute defined in MEF 45 [38] when applied to the UNI. See MEF 45 [38] for the possible values and requirements for this Service Attribute Subscriber UNI L2CP Peering Service Attribute The Subscriber UNI L2CP Peering Service Attribute is the L2CP Peering Service Attribute defined in MEF 45 [38] when applied to the UNI. See MEF 45 [38] for the possible values and requirements for this Service Attribute. 38 In MEF 10.3 [18] this is called UNI MEG Service Attribute. Page 79

90 [R100] When the value of the Subscriber UNI Link Aggregation Service Attribute (Section 10.5) = 2-Link Active/Standby or All Active, the value of the Subscriber UNI L2CP Peering Service Attribute MUST include the Link Aggregation Control/Marker Protocol (LACP). Note that [R100] is needed for consistency with [R69] and [R70]. [R101] When the value of the Subscriber UNI Link OAM Service Attribute (Section 10.16) = Enabled, the value of the Subscriber UNI L2CP Peering Service Attribute MUST include the Operations, Administration, and Maintenance (Link-OAM) protocol. Note that [R101] is needed for consistency with [R98]. Page 80

91 EVC EP Service Attributes 39 This section describes EVC EP Service Attributes. An EVC EP is a construct at a UNI that selects a subset of the Service Frames that pass over the UNI. Per Section 8.1 an EVC is an association of EVC EPs. An EVC EP represents the logical attachment of an EVC to a UNI EVC EP ID Service Attribute The value of the EVC EP ID Service Attribute is a string that is used to allow the Subscriber and Service Provider to uniquely identify the EVC EP for operations purposes. [R102] The value of the EVC EP ID Service Attribute MUST be unique among all such identifiers for EVC EPs in the Service Provider CEN. [R103] The value of the EVC EP ID Service Attribute MUST contain no more than 45 characters. 40 [R104] The value of the EVC EP ID Service Attribute MUST be a non-null RFC 2579 [12] DisplayString but not contain the characters 0x00 through 0x1f EVC EP UNI Service Attribute The value of the EVC EP UNI Service Attribute is a Subscriber UNI ID Service Attribute value per Section The value of the EVC EP UNI Service Attribute (Section 11.2) serves to specify the UNI where the EVC EP is located. The EVC EP is said to be at this UNI 11.3 EVC EP Role Service Attribute The value of the EVC EP Role Service Attribute is one of Root or Leaf. Note that because of [R9] and [R12], the value of the EVC EP Role Service Attribute will always have the value Root when the associating EVC is not of the type Rooted-Multipoint. See Section 9.2 for the definition of the EVC Type Service Attribute. For ease of exposition: An EVC EP with the value of the EVC EP Role Service Attribute = Root is called a Root EVC EP, and An EVC EP with the value of the EVC EP Role Service Attribute = Leaf is called a Leaf EVC EP. 39 In MEF 10.3 [18] these attributes are called EVC per UNI Service Attributes. 40 The limit of 45 characters is intended to establish limits on field lengths in existing or future protocols that will carry the identifier. Page 81

92 EVC EP Map Service Attribute The value of the EVC EP Map Service Attribute is a list of one or more CE-VLAN ID values. A Service Frame is mapped to the EVC EP if the CE-VLAN ID value of the Service Frame is in the list. The CE-VLAN ID value of a Service Frame is specified in Section 8.8. [R105] All ingress Service Frames at the UNI with a CE-VLAN ID value matching an entry in the value of the EVC EP Map Service Attribute MUST map to the EVC EP. [R106] All egress Service Frames that were delivered to the EVC End Point MUST have a CE-VLAN ID value matching an entry in the value of the EVC End Point Map Service Attribute. [R107] If CE-VLAN ID value 0 maps to an EVC EP that is in an EVC whose value of the EVC CE-VLAN ID Preservation Service Attribute = Disabled, then egress Service Frames mapped to the EVC EP MUST be Untagged Service Frames. [R106] means that egress VLAN Tagged Service Frames are required to have the VLAN ID value in the C-Tag set to one of the values in the value of the EVC End Point Map Service Attribute. It also means that if the value of the CE-VLAN ID Preservation Service Attribute (Section 9.6) = Enabled for an EVC where only a single CE-VLAN ID value is included in the value of the EVC End Point Map Service Attribute for each EVC End Point, it is required be the same CE-VLAN ID value at each EVC End Point. The case where multiple CE-VLAN ID values map to an EVC End Point is covered by [R22] and [R110]. Note that the EVC EP Map Service Attribute applies to both ingress and egress Service Frames. For an ingress Service Frame, the CE-VLAN ID value for the Service Frame and the value of the EVC EP Map Service Attribute enables the CEN to know how to deliver the Service Frame. For an egress Service Frame, the CE-VLAN ID value for the Service Frame and the value of the EVC EP Map Service Attribute allow the SE to know which EVC the Service Frame came from. [R108] At each UNI a given CE-VLAN ID value MUST be in at most one value of an EVC EP Map Service Attribute. [R109] When the value of the Subscriber UNI Maximum Number CE-VLAN IDs per EVC EP Service Attribute (Section 10.10) = 1 for a UNI, exactly one CE- VLAN ID value MUST be in the value of each EVC EP Service Map Service Attribute for EVC EPs located at the UNI. [R110] When more than one non-zero CE-VLAN ID value maps to an EVC EP that is in an EVC, the EVC EP Map Service Attributes for all EVC EPs in the EVC MUST have the same value. Figure 27 shows three examples of the value of the EVC EP Map Service Attribute. In this figure, there are three EVCs with values of the EVC ID Service Attribute (Section 9.1) being EVC 1, EVC 2, and EVC 3. Page 82

93 UNI B UNI A EVC EVC 2 Service Provider CEN EVC 3 UNI C UNI EVC End Point EVC EVC End Point Map Figure 27 Examples of the Value of the EVC EP Map Service Attribute In this example, an ingress VLAN Tagged Service Frame at UNI A with CE-VLAN ID value = 47 is transported according to the properties and attributes of EVC 1. An ingress Untagged or Priority Tagged Service Frame at UNI A is transported according to the properties and attributes of EVC 3. An egress Service Frame at UNI A coming from EVC 2 is given the CE-VLAN ID value = This equality with value of the CE-VLAN ID of the corresponding ingress Service Frame at UNI C could be because the value of the EVC CE-VLAN ID Preservation Service Attribute (Section 9.6) = Enabled or it could be just a coincidence if the value of the EVC CE-VLAN ID Preservation Service Attribute = Disabled. Figure 28 shows an example of the value of the Subscriber UNI Maximum Number of CE- VLAN IDs per EVC EP Service Attribute (Section 10.10) 3. In this example, UNI A and UNI B have the value of the Subscriber UNI Maximum Number of CE-VLAN IDs per EVC EP Service Attribute 3 as seen from the mapping for EVC EP a and EVC EP c. The EVC associating these two EVC EPs has the value of the EVC CE-VLAN ID Preservation Service Attribute = Enabled. Page 83

94 47,48,49 UNI B 1 c d 47,48, a e Service Provider CEN 47 UNI A b f UNI C UNI x EVC End Point EVC 113 EVC End Point Map Figure 28 Example of the value of the UNI Subscriber Maximum Number of CE-VLAN IDs per EVC EP Service Attribute 3 [R111] An ingress Service Frame with a CE-VLAN ID value that is not contained in any of the EVC EP Map Service Attribute values for the EVC EPs located at the ingress UNI MUST NOT result in a corresponding egress Service Frame that is mapped to any EVC EP in the CEN. Note that [R111] does not preclude processing ingress SOAM and L2CP Service Frames with a CE-VLAN ID value that does not map to an EVC EP, but such frames do not result in an egress Service Frame at any UNI. In scenarios where the value of the Subscriber UNI All to One Bundling Service Attribute (Section 10.11) = Disabled, the Subscriber and the Service Provider need to agree upon the values of the EVC EP Map Service Attribute for all EVC EPs located at the UNI. Also note that for a given UNI, the value of the EVC EP Map Service Attribute may be constrained by the range of CE- VLAN ID values that can be supported by the SE and the range of CE-VLAN ID values that can be supported by the Service Provider CEN. Page 84

95 CE-VLAN ID Significance When the value of the EVC CE-VLAN ID Preservation Service Attribute (Section 9.6) = Disabled, the value of the EVC EP Map Service Attribute for a given EVC EP can be different from the value of the EVC EP Map Service Attribute for another EVC EP in the EVC. However, in some cases it is mandated to be the same such as when the value of the EVC CE-VLAN ID Preservation Service Attribute = Enabled (9.6) or when an EVC includes an EVC EP to which more than one CE-VLAN ID value is mapped by the EVC EP Map Service Attribute (Section 11.4) ([R22]). Figure 29 shows valid values of the EVC EP Map Service Attribute for six EVC EPs. Note that when value of EVC CE-VLAN ID Preservation Service Attribute (Section 9.6) = Enabled for an EVC, the values of the EVC EP Map Service Attribute for EVC EPs that are in the EVC are identical as is the case for EVC 1 in Figure 29. Otherwise the CE-VLAN ID value cannot be preserved. Note that CE-VLAN ID value 0 is not included in the value of the EVC EP Map Service Attributes at UNI A, UNI B, and UNI D. UNI B UNI A EVC 1 EVC 2 Service Provider CEN 0,17 UNI C EVC 3 UNI D 1343 UNI EVC End Point EVC EVC End Point Map Figure 29 Examples of Valid EVC EP Map Service Attribute Values Describing the Value of the EVC EP Map Service Attribute This document does not constrain how the value of the EVC EP Map Service Attribute can be described in a protocol, database, service order form, etc. For example, shorthand descriptions such as the example of Figure 24 are allowed. Page 85

96 EVC EP Ingress Class of Service Map Service Attribute 41 The value of the EVC EP Ingress Class of Service Map Service Attribute is a 3-tuple of the form F, M, P where F is a protocol field in the ingress Service Frame, M is a map that maps each possible value of the field F and the absence of the field F to a Class of Service Name and P is a map of Layer 2 Control Protocol types as determined by the Protocol Identifier (see Section 6.2 of MEF 45 [38]) to Class of Service Names. The value of F is one of EVC EP, C-Tag PCP, or DSCP. When the value of F = DSCP, M can map a DSCP value to two different Class of Service Names, one Class of Service Name for ingress Service Frames carrying an IPv4 packet and a different Class of Service Name for ingress Service Frames carrying an IPv6 packet. The map P can map just a subset of all possible L2CP Protocol Identifiers (per Section 6.2 of MEF 45 [38]) and is allowed to be null. Each ingress Service Frame mapped to the given EVC EP has a single Class of Service Name. The Class of Service Name can be determined from inspection of the content of the ingress Service Frame. As described in Section 6.2 of MEF 23.2 [25], the Class of Service Name is used to identify the Performance Metrics and associated Performance Metric Objectives that apply to the ingress Service Frame as described in Section 9.10 of this document. Note that the Class of Service Name could be one of the Class of Service Labels standardized in MEF 23.2 [25]. For example, for the given EVC EP at the UNI, there could be three Class of Service Names called Silver, Gold, and Platinum. [R112] An ingress Service Frame that has the Class of Service Name Discard MUST be discarded. The values of F, M, and P can be different for each EVC EP that is associated by an EVC. The requirements regarding the EVC EP Ingress Class of Service Map Service Attribute for Data Service Frames and SOAM Service Frames are different than they are for Layer 2 Control Protocol Service Frames as detailed below EVC EP Ingress Class of Service Map Service Attribute for Data Service Frames [R113] If an ingress Data Service Frame is mapped to an EVC EP, then the Class of Service Name for this Service Frame MUST be the Class of Service Name mapped to by M. Sections , , and describe the EVC EP Ingress Class of Service Map Service Attribute for each of the possible values of F. 41 In MEF 10.3 [18] this is called Class of Service Identifier Service Attribute. Page 86

97 EVC EP Ingress Class of Service Map Service Attribute Based on EVC EP When the value of F = EVC EP, the map M is based on EVC EP. This means that the field(s) used to determine the EVC EP that the ingress Service Frame is mapped to via the value of the EVC EP Map Service Attribute (Section 11.4) are also used to determine Class of Service name. [R114] When the value of F = EVC EP for an EVC EP, M MUST contain a single Class of Service Name. [R115] When the value of F = EVC EP for an EVC EP, the Class of Service Name contained in M MUST NOT be Discard. [R114] and [R115] mean that a single Class of Service Name applies to all ingress Data Service Frames mapped to the EVC EP. As an example, consider EVC EP 1 and EVC EP 2 located at a UNI. Ingress Data Service Frames mapped to EVC EP 1 have the Class of Service Name Gold. Ingress Data Service Frames mapped to EVC EP 2 have the Class of Service Name Silver EVC EP Ingress Class of Service Map Service Attribute Based on Priority Code Point Field When the value of F = C-Tag PCP, the map M is based on C-Tag Priority Code Point. [R116] When the value of F = C-Tag PCP for an EVC EP, M MUST map each possible C-Tag PCP value to exactly one Class of Service Name and each ingress Service Frame without a C-Tag to exactly one Class of Service Name. [R116] means that the sets of C-Tag Priority Code Point values that each map to a different Class of Service Name are disjoint sets and the union of all such sets is the set of all possible C-Tag Priority Code Point values. [R116] also means that each ingress Data Service Frame mapped to the EVC EP has a single Class of Service Name that applies to it [D5] When the value of F = C-Tag PCP for an EVC EP, the Class of Service Name for all ingress Data Service Frames mapped to the EVC EP without a C-Tag SHOULD be the same Class of Service Name as that for ingress Data Service Frames mapped to the EVC EP with a C-Tag that has the Priority Code Point value = Table 20 shows examples of the mapping of PCP value to Class of Service Name for two different EVC EPs at a UNI. Page 87

98 EVC EP A EVC EP B PCP Value Class of Service Name PCP Value Class of Service Name 0 Silver 0 Gold 1 Discard 1 Gold 2 Discard 2 Gold 3 Silver 3 Gold 4 Gold 4 Gold 5 Gold 5 Gold 6 Gold 6 Gold 7 Gold 7 Platinum Untagged Silver Untagged Gold Table 20 Examples of Mapping PCP Value to Class of Service Name Note that a single Class of Service Name for all ingress Service Frames mapped to an EVC EP can be achieved by mapping all possible PCP values and Untagged to the same Class of Service Name. This is the same behavior as when F = EVC EP EVC EP Ingress Class of Service Map Service Attribute Based on Internet Protocol When the value of F = DSCP, the map M is based on Internet Protocol. This means that the Class of Service Name is determined from the value of the DSCP for an ingress Data Service Frame carrying an IPv4 or an IPv6 packet [O5] When the value of F = DSCP for an EVC EP, M MAY be such that a value of DSCP maps to one Class of Service Name for an ingress Data Service Frame carrying an IPv4 packet and maps to a different Class of Service Name for an ingress Data Service Frame carrying an IPv6 packet [R117] When the value of F = DSCP for an EVC EP, M MUST be such that each possible DSCP value maps to exactly one Class of Service Name for ingress Data Service Frames carrying an IPv4 packet. [R118] When the value of F = DSCP for an EVC EP, M MUST be such that each possible DSCP value maps to exactly one Class of Service Name for ingress Data Service Frames carrying an IPv6 packet. [R119] When the value of F = DSCP for an EVC EP, M MUST map each ingress Data Service Frame that is not carrying either an IPv4 or IP6 packet and that is mapped to the EVC EP to exactly one Class of Service Name. [R117] and [R118] mean that each possible <IP version, DSCP value> pair maps to exactly one Class of Service Name. Table 21 shows an example of using the EVC EP Ingress Class of Service Map Service Attribute based on Internet Protocol. In this example an ingress Data Service Frame carrying an IPv4 packet with DSCP = 37 would have the Class of Service Name Platinum. Similarly, an ingress Data Service Frame carrying an IPv6 packet with DSCP = 37 would have the Class of Service Page 88

99 Name Platinum. In this example Diamond can only apply to ingress Data Service Frames carrying an IPv4 packet and Ruby can only apply to ingress Data Service Frames carrying an IPv6 packet. This example illustrates [O5] that allows a mapping of a DSCP value to Class of Service name for IPv4 that is different than the mapping of a DSCP value to Class of Service Name for IPv6. IPv4 DSCP Values IPv6 DSCP Values Class of Service Name 11,37,45 11,37,45 Platinum 8,10,12 Diamond 38,213 Ruby No IP Packet No IP Packet Quartz All other values All other values Discard Table 21 Example of M when F Equals DSCP Table 22 shows an example where only IPv4 is supported. In this example, the Class of Service Name for ingress Data Service Frames not carrying an IP packet is Good Enough. This fact and the last row in Table 22 means that Good Enough applies to any ingress Data Service Frame not carrying an IPv4 packet. Consequently, IPv6 is not recognized but instead is treated as non-ip. A similar approach can be used to support only IPv IPv4 DSCP Values IPv6 DSCP Values Class of Service Name 11,37,45 Superior 8,10,12 Near Superior All other values Discard No IP Packet No IP Packet Good Enough All values Good Enough Table 22 Example of M that Only Supports IPv4 when F Equals DSCP EVC EP Ingress Class of Service Map Service Attribute for Layer 2 Control Protocol Service Frames [R120] If an ingress Layer 2 Control Protocol Service Frame is mapped to an EVC EP and the Layer 2 Control Protocol carried by this ingress Layer 2 Control Protocol Service Frame is contained in the value of the map P, then the Class of Service Name for this frame MUST be the Class of Service Name mapped to by P. [R121] If an ingress Layer 2 Control Protocol Service Frame is mapped to an EVC EP and the Layer 2 Control Protocol carried by this ingress Layer 2 Control Protocol Service Frame is not contained in the map P, then the Class of Service Name for this frame MUST be determined as if it is an ingress Data Service Frame. Page 89

100 EVC EP Ingress Class of Service Map Service Attribute for SOAM Service Frames [R122] If an ingress SOAM Service Frame is mapped to an EVC EP, then the Class of Service Name for this ingress SOAM Service Frame MUST be the same as if it were an ingress Data Service Frame EVC EP Color Map Service Attribute 42 Editor Note 14: During the 5/10/2017 conference call, it was agreed to make F apply to both ingress and egress Service Frames but M only apply to ingress Service Frames. This means that the Service Provider does not know how the SE interprets color marking. The Subscriber, via the EVC EP Egress Map Service Attribute, can have the CEN properly set color on egress Service Frames for use by the SE. However, if there is an Egress Bandwidth Profile with CM i = coloraware for Bandwidth Profile Flow i, the CEN needs to know the value of M used by the SE in order to implement the Egress Bandwidth Profile. The text is in this section is edited in WD 18 to have F and M apply to both ingress and egress Service Frames. This is the same behavior specified in MEF The value of the EVC EP Color Map Service Attribute is a pair of the form <F, M> where F is a field in the Service Frame and M is a mapping between each possible value of the field F and a Color. The value of F is one of EVC EP, C-Tag DEI, C-Tag PCP, or DSCP. The EVC EP Color Map Service Attribute is the mechanism by which the Color for a Service Frame that is mapped to an EVC EP is indicated by the content in the Service Frame header. The color identified for an ingress Service Frame is used to determine if it is a Qualified Service Frame (Section ) and if it is subject to the One-way Availability Performance Metric (Section ) when: The Service Frame is not in an ingress Bandwidth Profile Flow (Section 13) or The Service Frame is in an ingress Bandwidth Profile Flow i (Section 13) and CM i = color-aware (Section ) [R123] The Color for a Service Frame MUST be either Green or Yellow. Editor Note 15: The following requirement is redundant with the above text. Should it be deleted? [R124] The value of F MUST be one of EVC EP, C-Tag DEI, C-Tag PCP or DSCP. Sections through contain requirements for each of the above values of F. 42 In MEF 10.3 [18] this is called Color Identifier Service Attribute. Page 90

101 EVC EP Color Map Service Attribute with F = EVC EP The value of F = EVC EP means that the field(s) used to determine the EVC EP that the Service Frame is mapped to via the value of the EVC EP Map Service Attribute (Section 11.4) are also used to determine the Color. [R125] When the value of F = EVC EP, M MUST contain exactly on Color. [R125] means that a single Color applies to all Service Frames mapped to the EVC EP EVC EP Color Map Service Attribute with F = C-Tag DEI [R126] When the value of F = C-Tag DEI, M MUST be such that the C-Tag DEI = 0 maps to Green and C-Tag DEI = 1 maps to Yellow. [R127] When the value of F is C-Tag DEI, the Color of a Service Frame without a C- Tag MUST be Green. EVC EP Color Map Service Attribute with F = C-Tag PCP [R128] When the value of F = C-Tag PCP, M MUST be such that each possible value of the C-Tag PCP maps to a Color. [R129] When the value of F = C-Tag PCP, the Color of a Service Frame without a C- Tag MUST be Green [R128] means that the sets of C-Tag PCP values that map to each Color are disjoint sets and the union of these sets is the set of all possible C-Tag PCP values EVC EP Color Map Service Attribute with F = DSCP [O6] When the value of F = DSCP, M MAY be such that a value of DSCP maps to one Color for a Service Frame carrying an IPv4 packet and maps to a different Color for a Service Frame carrying an IPv6 packet [R130] When the value of F = DSCP, M MUST be such that each possible DSCP value maps to exactly one Color for Service Frames carrying an IPv4 packet. [R131] When the value of F = DSCP, M MUST be such that each possible DSCP value maps to exactly one Color for Service Frames carrying an IPv6 packet. [R132] When the value of F = DSCP, the Color of a Service Frame that does not contain either an IPv4 or an IPv6 packet MUST be Green. Note that the mapping of DSCP values to Color can be different for IPv4 and IPv6. Table 23 shows an example of the use of different mappings for IPv4 and IPv6. Page 91

102 IPv4 DSCP Values IPv6 DSCP Values Color 1,2,3,5,7,11,13,17 1,2,3,5,8,13,21,34 Yellow All other values All other values Green Table 23 Example of DSCP to Color Mapping 11.7 EVC EP Egress Map Service Attribute The value of the EVC EP Egress Map Service Attribute is a set of mappings that determine the content of the C-Tag of an egress C-Tagged Service Frame. There are three forms of the EVC EP Egress Map Service Attribute value: CNC-Tag PCP, CCC-Tag DEI, and CCC-Tag PCP. The three forms are used in populating the C-Tag in an egress Service Frame based on the Class of Service Name and Color of the corresponding ingress Service Frame. Section 11.5 details the determination of the Class of Service Name for ingress Service Frames. The Color of an ingress Service Frame is determined by the Ingress Bandwidth Profile that is applied to it or according to the value the EVC EP Color Map Service Attribute (Section 11.6) if no Ingress Bandwidth Profile is applied. Per Section , under some conditions, no value is needed for the EVC EP Egress Map while under other conditions values for more than one form of EVC EP Egress Map Service Attribute are needed. Note that the EVC EP Egress Map Service Attribute does not apply to egress SOAM Service Frames and egress Layer 2 Control Protocol Service Frames that are a result of frames generated inside the Service Provider CEN. Populating the C-Tag for Service Frames that are a result of frames generated inside the Service Provider CEN are beyond the scope of this document. The three forms of the value of the EVC EP Egress Map Service Attribute are described in Sections through Requirements on the use of the EVC EP Egress Map Service Attribute are contained in Section EVC EP Egress Map Form CNC-Tag PCP The EVC EP Egress Map Service Attribute Form CNC-Tag PCP is a set of mappings of the form <Corresponding ingress Service Frame Class of Service Name> to either <Egress Service Frame C-Tag PCP value> or <Discard>. [R133] The EVC EP Egress Map Service Attribute Form CN->C-Tag PCP value MUST contain exactly one entry for each Class of Service Name in the value of the EVC List of Class of Service Names Service Attribute (Section 9.9) value other than Discard. Table 24 contains an example for the EVC List Class of Service Names Service Attribute value in Table 6. Page 92

103 Ingress Class of Service Name Egress C-Tag PCP Value Platinum 7 Gold 5 Silver Discard Table 24 Example of the EVC EP Egress Map Service Attribute Form CNC-Tag PCP EVC EP Egress Map Form CCC-Tag DEI The EVC EP Egress Map Service Attribute Form CCC-Tag DEI is a set of mappings of the form <Corresponding ingress Service Frame Class of Service Name, Corresponding ingress Service Frame Color> to either <Egress Service Frame C-Tag DEI value> or <Discard>. [R134] The EVC EP Egress Map Service Attribute Form CCC-Tag DEI MUST have two entries for each Class of Service Name in the value of the EVC List of Class of Service Names Service Attribute (Section 9.9) that is not Discard, one entry with the Color Green and one entry with the Color Yellow. Table 25 contains an example for the EVC List of Class of Service Names value in Table Ingress Class of Service Name Ingress Color Egress C-Tag DEI Value Platinum Green 0 Platinum Yellow 1 Gold Green 0 Gold Yellow Discard Silver Green 1 Silver Yellow 1 Table 25 Example of the EVC EP Egress Map Service Attribute Form CCC-Tag DEI EVC EP Egress Map Form CCC-Tag PCP The EVC EP Egress Map Service Attribute Form CCC-Tag PCP is a set of mappings of the form <Corresponding ingress Service Frame Class of Service Name, Corresponding ingress Service Frame Color> to either <Egress Service Frame C-Tag PCP value> or <Discard>. [R135] The EVC EP Egress Map Service Attribute Form CCC-Tag PCP MUST have two entries for each Class of Service Name in the value of the EVC List of Class of Service Names Service Attribute (Section 9.9) that is not Discard, one entry with the Color Green and one entry with the Color Yellow. Table 26 contains an example for the EVC List Class of Service Names Service Attribute value in Table 6. Page 93

104 Ingress Class of Service Name Ingress Color Egress C-Tag PCP Value Platinum Green 7 Platinum Yellow 6 Gold Green 5 Gold Yellow Discard Silver Green 3 Silver Yellow 2 Table 26 Example of the EVC EP Egress Map Service Attribute Form CCC-Tag PCP EVC EP Egress Map Service Attribute Requirements The following requirement mandates how to set the C-Tag PCP value and DEI value in an egress Service Frame, if present. Note that the value of the EVC EP Egress Map depends on: The value of the EVC EP Egress Equivalence Class Map Service Attribute (Section 11.8) and The basis for the EVC EP Color Map Service Attribute (Section 11.6). [R136] The EVC EP Egress Map Forms used to populate the C-Tag PCP and C-Tag DEI of an egress C-Tagged Service Frame MUST be as shown in Table 27. The forms of EVC EP Egress Map that are required as specified in Table 27 depend on the Basis for the EVC EP Color Identifier (Section 11.6) for the EVC EP. Page 94

105 EVC CE- VLAN PCP Preservation Value EVC CE- VLAN DEI Preservation Value EVC EP Egress Equivalence Class Identifier F Value EVC EP Color Identifier F Value EVC EP Egress Map Form C-Tag in Corresponding ingress Corresponding No C-Tag in Service Frame ingress Service Frame* Enabled Enabled C-Tag PCP C-Tag DEI None CNC-Tag PCP and CCC-Tag DEI Enabled Enabled C-Tag PCP C-Tag None CCC-Tag PCP PCP Enabled Enabled C-Tag PCP DSCP or None CNC-Tag PCP EVC EP Enabled Enabled DSCP C-Tag DEI None CCC-Tag DEI Enabled Enabled DSCP C-Tag None CCC-Tag PCP PCP Enabled Enabled DSCP DSCP or None None EVC EP Enabled Disabled C-Tag PCP C-Tag DEI CCC-Tag DEI CNC-Tag PCP and CCC-Tag DEI Enabled Disabled C-Tag PCP C-Tag None CCC-Tag PCP PCP Enabled Disabled C-Tag PCP DSCP or None CNC-Tag PCP EVC EP Enabled Disabled DSCP C-Tag DEI CCC-Tag DEI CCC-Tag DEI Enabled Disabled DSCP C-Tag None CCC-Tag PCP PCP Enabled Disabled DSCP DSCP or None None EVC EP Disabled Enabled C-Tag PCP C-Tag DEI CNC-Tag PCP CNC-Tag PCP and CCC-Tag DEI Disabled Enabled C-Tag PCP C-Tag CCC-Tag PCP CCC-Tag PCP PCP Disabled Enabled C-Tag PCP DSCP or CNC-Tag PCP CNC-Tag PCP EVC EP Disabled Enabled DSCP C-Tag DEI None CCC-Tag DEI Disabled Enabled DSCP C-Tag CCC-Tag PCP CCC-Tag PCP PCP Disabled Enabled DSCP DSCP or None None EVC EP Disabled Disabled C-Tag PCP C-Tag DEI CNC-Tag PCP and CCC-Tag DEI CNC-Tag PCP and CCC-Tag DEI CCC-Tag PCP Disabled Disabled C-Tag PCP C-Tag PCP CCC-Tag PCP Disabled Disabled C-Tag PCP DSCP or CNC-Tag PCP CNC-Tag PCP EVC EP Disabled Disabled DSCP C-Tag DEI CCC-Tag DEI CCC-Tag DEI Page 95

106 EVC CE- VLAN PCP Preservation Value EVC CE- VLAN DEI Preservation Value EVC EP Egress Equivalence Class Identifier F Value EVC EP Color Identifier F Value EVC EP Egress Map Form C-Tag in Corresponding ingress Corresponding No C-Tag in Service Frame ingress Service Frame* CCC-Tag PCP CCC-Tag PCP Disabled Disabled DSCP C-Tag PCP Disabled Disabled DSCP DSCP or None None EVC EP *This column applies when the egress Service Frame needs to have a C-Tag. When there is not a C-Tag in the egress Service Frame, then no egress map is needed. Note that preservation of the CE-VLAN PCP and the CE-VLAN DEI is not required for ingress Untagged Service Frames per [R23] and [R24]. Table 27 EVC EP Map Form Usage for an EVC EP at a UNI and the Egress Service Frame Has a C-Tag Note that Table 27 takes into account when the content of a C-Tag in an ingress Service Frame is mandated to be preserved via the EVC CE-VLAN PCP Preservation Service Attribute (Section 9.7) value and/or the EVC CE-VLAN DEI Preservation Service Attribute (Section 9.8) value. In Table 27 when the specified EVC EP Egress Map forms mandated do not provide a value for the C-Tag DEI, the C-Tag DEI can have an arbitrary value. An entry of None in Table 27 means that no EVC EP Egress Map needs to be used to properly specify the C-Tag PCP and C-Tag DEI values. It might not be necessary to specify all of the EVC EP Egress Map forms. For example, if the conditions of the last row of Table 27 are always met for an EVC EP, no EVC EP Egress Map form needs to be specified [D6] When the value of F in the value of the EVC EP Egress Equivalence Class Map Service Attribute is C-Tag DSCP (Section 11.8), the basis for the EVC EP Color Map Service Attribute (Section 11.6) is C-Tag PCP, and the EVC EP Egress Map form used is CCC-Tag PCP, the value of the EVC EP Egress Map Service Attribute SHOULD be such that only two values of C-Tag PCP result from applying the map EVC EP Egress Equivalence Class Map Service Attribute 43 The value of the EVC EP Egress Equivalence Class Map Service Attribute is a 3-tuple of the form F, M, P where F is a protocol field in the egress Service Frame, M is a map that maps each possible value of the field F and the absence of the field F to an Egress Equivalence Class Name and P is a map of L2CP Protocol Identifier (per Section 6.2 of MEF 45 [38]) to Egress Equivalence Class Name. The value of F is one of C-Tag PCP, or DSCP. When the value of F is DSCP, M can map a DSCP value to two different Egress Equivalence Class Names, one for egress Service Frames carrying an IPv4 packet and a different one for egress Service Frames carrying an IPv6 packet. The map P can map just a subset of all possible L2CP Protocol Identifiers and is allowed to be null. 43 In MEF 10.3[18] this is called Egress Equivalence Class Identifier Service Attribute. Page 96

107 Each egress Service Frame mapped to the given EVC EP has a single Egress Equivalence Class Name. The Egress Equivalence Class Name can be determined from inspection of the content of the egress Service Frame. The Egress Equivalence Class Name is used to specify Egress Bandwidth Profile Service Attributes as described in Sections 10.15, 11.11, and When there is no EVC EP Egress Equivalence Class Name Bandwidth Profile Service Attribute (Section 11.11) whose value = CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F, for an EVC EP, i.e., there are no Egress Equivalence Class Name Bandwidth Profile Flows, the values of M and P in the EVC EP Egress Equivalence Class Map Service Attribute have no effect. It is possible to have only a single Egress Equivalence Class Name. For an EVC EP, the value of F can be set to C-Tag PCP and M can be set to map all Service Frames to a single Egress Equivalence Class Name. In such cases, an Egress Equivalence Class Name Bandwidth Profile Flow is indistinguishable from an Egress EVC EP Bandwidth Profile Flow. The values of F, M, and P can be different for each EVC EP that is associated by an EVC. [R137] The map M MUST be used to determine the Egress Equivalence Class Name for each egress Data Service Frame. The requirements regarding the EVC EP Egress Equivalence Class Map Service Attribute for Data Service Frames and SOAM Service Frames are different than they are for Layer 2 Control Protocol Service Frames EVC EP Egress Equivalence Class Map Service Attribute for Egress Data Service Frames Based on C-Tag Priority Code Point When the value of F = C-Tag PCP, the map M is based on C-Tag priority Code Point. [R138] When the value of F = C-Tag PCP, M MUST map each possible C-Tag PCP value and each egress Service Frame without a C-Tag to exactly one Egress Equivalence Class Name. [R138] means that the sets of C-Tag Priority Code Point values that each map to an Egress Equivalence Class Name are disjoint sets and the union of all such sets is the set of all possible C-Tag Priority Code Point values. [R138] also means that each egress Data Service Frame mapped to the EVC EP has a single Egress Equivalence Class Name that applies to it. Table 28 shows examples of the mapping of PCP value to Egress Equivalence Class Name for two different EVC EPs at a UNI. Page 97

108 EVC EP A EVC EP B PCP Value Egress Equivalence Class Name PCP Value Egress Equivalence Class Name 0 mycetes 0 mycetes 1 opsida 1 mycetes 2 opsida 2 mycetes 3 opsida 3 mycetes 4 phyceae 4 mycetes 5 phyceae 5 opsida 6 phyceae 6 opsida 7 phyceae 7 opsida Untagged opsida Untagged opsida Table 28 Examples of Mapping PCP Value to Egress Equivalence Class Name EVC EP Egress Equivalence Class Map Service Attribute for Egress Data Service Frames Based on Internet Protocol When the EVC EP Egress Equivalence Class Identifier is based on Internet Protocol for an EVC EP, the value of F = DSCP. This means that the Egress Equivalence Class Name is determined from value of the DSCP for an egress Data Service Frame carrying an IPv4 or an IPv6 packet [O7] When the value of F = DSCP, M MAY be such that a value of DSCP maps to one Egress Equivalence Class Name for an egress Data Service Frame carrying an IPv4 packet and maps to a different Egress Equivalence Class Name for an egress Data Service Frame carrying an IPv6 packet [R139] When the value of F = DSCP, M MUST be such that each possible DSCP value maps to exactly one Egress Equivalence Class Name for egress Data Service Frames carrying an IPv4 packet that are mapped to the EVC EP. [R140] When the value of F = DSCP, M MUST be such that each possible DSCP value maps to exactly one Egress Equivalence Class Name for egress Data Service Frames carrying an IPv6 packet that are mapped to the EVC EP. [R141] When the value of F = DSCP, M MUST map each egress Service Frame that is not carrying either an IPv4 or IP6 packet and that is mapped to the EVC EP to exactly one Egress Equivalence Class Name. Table 29 shows an example of using the EVC EP Egress Equivalence Class Map Service Attribute based on Internet Protocol. In this example an egress Data Service Frame carrying an IPv4 packet with DSCP = 37 would be in the Egress Equivalence Class Name Sophomore. Similarly, an egress Data Service Frame carrying an IPv6 packet with DSCP = 37 would be in the Egress Equivalence Class Name Sophomore. In this example Senior can only apply to egress Data Service Frames carrying an IPv4 packet and Junior can only apply to egress Data Service Frames carrying an IPv6 packet. Page 98

109 IPv4 DSCP Values IPv6 DSCP Values Egress Equivalence Class Name 11,37,45 11,37,45 Sophomore 8,10,12 Senior 38,213 Junior No IP Packet No IP Packet Freshman All other values All other values Freshman Table 29 Example of M when F equals DSCP Table 30 shows an example where only IPv4 is supported. In this example, the Egress Equivalence Class Name for egress Data Service Frames not carrying an IP packet is Baggage. This fact and the last row of Table 30 means that Baggage applies to any egress Data Service Frame not carrying an IPv4 packet. An analogous approach can be used for the case where only IPv6 is supported IPv4 DSCP Values IPv6 DSCP Values Egress Equivalence Class Name 11,37,45 First 8,10,12 Business No IP Packet No IP Packet Baggage All other values Economy All values Baggage Table 30 Example of M that Only Supports IPv4 when F Equals DSCP EVC EP Egress Equivalence Class Map Service Attribute for Egress L2CP Service Frames [R142] If an egress Layer 2 Control Protocol Service Frame is mapped to an EVC EP and the Layer 2 Control Protocol carried by this egress Layer 2 Control Protocol Service Frame is contained in the map P, then the Egress Equivalence Class Name for this frame MUST be the Egress Equivalence Class Name mapped to by the Layer 2 Control Protocol [R143] If an egress Layer 2 Control Protocol Service Frame is mapped to an EVC EP and the Layer 2 Control Protocol carried by this egress Layer 2 Control Protocol Service Frame is not contained in the map P, then the Egress Equivalence Class Name for this frame MUST be determined as if it is an egress Data Service Frame. EVC EP Egress Equivalence Class Map Service Attribute for Egress SOAM Service Frames [R144] If an egress SOAM Service Frame is mapped to an EVC EP, then the Egress Equivalence Class Name for this egress SOAM Service Frame MUST be the same as if it were an egress Data Service Frame. Page 99

110 EVC EP Ingress Bandwidth Profile Service Attribute 44 The value of the EVC EP Ingress Bandwidth Profile Service Attribute is either Disabled or the 10-tuple CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F where each item in the 10-tuple is defined in Section [R145] When the value of the EVC EP Ingress Bandwidth Profile Service Attribute = CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F, the CEN MUST apply Bandwidth Profile Algorithm (Section 13.2) using these parameter values to the Ingress EVC EP Bandwidth Profile Flow (Section 13). [R146] An ingress Service Frame that is declared Red by the application of the Bandwidth Profile Algorithm per [R145] MUST be discarded. Note that if an ingress Service Frame is declared Green and it meets other conditions per the definition of Qualified Service Frame in Section , then the SLS applies to this Service Frame. Note that, per the definition of Qualified Service Frame in in Section , an ingress Service Frame that is declared Yellow is not subject to the Performance Metrics and associated Performance Metric Objectives of the SLS. The better the level of Bandwidth Profile compliance, the fewer Service Frames will be discarded. In order to improve the level of Bandwidth Profile compliance, a Subscriber may need to shape traffic in the SE (Appendix B contains a shaping example). If a UNI has 3 EVC EPs, there could be one Envelope containing three Bandwidth Profile Flows, one for each EVC EP. In such a case, each set of parameters for a Bandwidth Profile Flow described in Section 13 would be associated with a different EVC EP at the UNI. When an Envelope contains a single Ingress EVC EP Bandwidth Profile Flow, then the behavior is exactly that of Ingress Bandwidth Profile per EVC described in MEF 10.2 [17]. (Section 13.3.) Figure 30 illustrates an example of the application of the EVC EP Ingress Bandwidth Profile Service Attribute. In this example, EVC EP 1 corresponds to Bandwidth Profile Flow 1 with CIR 1 1 = CIR max = 15Mbps, EVC EP 2 corresponds to Bandwidth Profile Flow 2 with CIR 2 = 2 = 10Mbps, and EVC EP 3 corresponds to Bandwidth Profile Flow 3 with CIR 3 = CIR max CIR max 3 = 20Mbps. 44 In MEF 10.3 [18] this is called Ingress Bandwidth Profile per EVC Service Attribute. Page 100

111 2528 EVC EP 1 Bandwidth Profile Flow 1 UNI EVC EP 2 Bandwidth Profile Flow 2 Envelope EVC EP 3 Bandwidth Profile Flow Figure 30 EVC EP Ingress Bandwidth Profile Service Attribute Example EVC EP Class of Service Name Ingress Bandwidth Profile Service Attribute 45 The value of the EVC EP Class of Service Name Ingress Bandwidth Profile Service Attribute is a list of pairs of the form x, y where x is a Class of Service Name that is in the value of the EVC List of Class of Service Names Service Attribute (Section 9.9) for the EVC that associates the EVC EP and y = the 10-tuple CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F where each item in the 10-tuple is defined in Section Each Class of Service Name that is in the value of the EVC List of Class of Service Names Service Attribute for the EVC that associates the EVC EP can appear at most once in the list of pairs x, y. However the Class of Service Name Discard cannot appear in the list of pairs x, y. [R147] When the value of y = CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F in the pair x, y, the CEN MUST apply the Bandwidth Profile Algorithm (Section 13.2) using these parameter values to the Ingress Class of Service Name Bandwidth Profile Flow (Section 13) for the Class of Service Name x. [R148] An ingress Service Frame that is declared Red by the application of the Bandwidth Profile Algorithm per [R147] MUST be discarded. Note if there is no need to apply the Bandwidth Profile Algorithm to ingress Service Frames with a given Class of Service Name, e.g., the Class of Service Name is not used at the UNI, then this 45 In MEF 10.3 [18] this is called Ingress Bandwidth Profile per Class of Service Identifier Service Attribute. Page 101

112 Class of Service Name can be omitted from the list of x, y s. This obviates the need to specify parameter values for a Bandwidth Profile Flow that will never be used. Note that if an ingress Service Frame is declared Green and it meets other conditions per the definition of Qualified Service Frame in Section , then the SLS applies to this Service Frame. Note that, per the definition of Qualified Service Frame in in Section , an ingress Service Frame that is declared Yellow is not subject to the Performance Metrics and associated Performance Metric Objectives of the SLS. The better the level of Bandwidth Profile compliance, the fewer Service Frames will be discarded. In order to improve the level of Bandwidth Profile compliance, a Subscriber may need to shape traffic in the SE (Appendix B contains a shaping example). Figure 31 illustrates an example of the application of EVC EP Class of Service Name Ingress Bandwidth Profile Service Attribute. In this example, Gold corresponds to Bandwidth Profile Flow 1 with CIR 1 1 = CIR max = 15Mbps, Silver corresponds to Bandwidth Profile Flow 2 with CIR 2 2 = CIR max = 10Mbps, and Straw corresponds to Bandwidth Profile Flow 3 with CIR 3 = 3 = 20Mbps. CIR max Gold Bandwidth Profile Flow 1 EVC EP Silver Bandwidth Profile Flow 2 Envelope Straw Bandwidth Profile Flow Class of Service Names: Gold, Silver, Straw Figure 31 EVC EP Class of Service Name Ingress Bandwidth Profile Service Attribute Example Page 102

113 EVC EP Egress Bandwidth Profile Service Attribute 46 The value of the EVC EP Egress Bandwidth Profile Service Attribute is either Disabled or the 10-tuple CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F where each item in the 10-tuple is defined in Section [R149] When the value of the EVC EP Egress Bandwidth Profile Service Attribute = CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F, the application of the Bandwidth Profile Algorithm (Section 13.2) using these parameter values to the EVC EP Egress Bandwidth Profile Flow (Section 13) MUST result in each egress Service Frame being declared Green or Yellow. The implication of [R149] is that the Subscriber will receive a sequence of egress Service Frames that conforms to the Bandwidth Profile with parameters CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F. In other words, the handling of the Service Frames in the CEN is such that all egress Service Frames that would be declared Red if the Subscriber applied the Bandwidth Profile Algorithm to the Bandwidth Profile Flow are discarded before reaching the egress UNI. It is important to reiterate that this description does not mandate or constrain in any way the implementation in the Service Provider CEN. Note that Service Frames discarded in order to meet [R149] can affect the One-way Frame Loss Ratio Performance Metric (Section ). Likewise Service Frames buffered in order to meet [R149] can affect one-way frame delay and delay variation. Therefore, the parameter values for the EVC EP Egress Equivalence Class Name Bandwidth Profile Service Attribute need to be set carefully so that meeting [R149] does not cause the Performance Metric objectives of the SLS to be missed. When an Envelope contains a single Egress EVC EP Bandwidth Profile Flow, then the behavior is exactly that of the Egress Bandwidth Profile per EVC described in MEF 10.2 [17] EVC EP Egress Equivalence Class Name Bandwidth Profile Service Attribute 47 The value of the EVC EP Egress Equivalence Class Name Bandwidth Profile Service Attribute is a list of pairs of the form x, y where x is an Egress Equivalence Class Name and y = the 10- tuple CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F where each item in the 10-tuple is defined in Section There is at most one pair in the list for each Egress Equivalence Class Name. [R150] When the value of y = CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F in the pair x, y, the application of the Bandwidth Profile Algorithm (Section 13.2) using these parameter values to the Egress Equivalence Class Name Bandwidth Profile Flow (Section 13) for Egress Equivalence Class Name x MUST result in each egress Service Frame being declared Green or Yellow. 46 In MEF 10.3 [18] this is called Egress Bandwidth Profile per EVC Service Attribute. 47 In MEF 10.3 [18] this is called Egress Bandwidth Profile per Egress Equivalence Class Identifier Service Attribute. Page 103

114 The implication of [R150] is that the Subscriber will receive a sequence of egress Service Frames that conforms to the Bandwidth Profile with parameters CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F. In other words, the handling of the Service Frames in the CEN is such that all egress Service Frames that would be declared Red if the Subscriber applied the Bandwidth Profile Algorithm to the Bandwidth Profile Flow are discarded before reaching the egress UNI. It is important to reiterate that this description does not mandate or constrain in any way the implementation in the Service Provider CEN. Note that Service Frames discarded in order to meet [R150] can affect the One-way Frame Loss Ratio Performance Metric (Section ). Likewise Service Frames buffered in order to meet [R150] can affect one-way frame delay and delay variation. Therefore, the parameter values for the EVC EP Egress Equivalence Class Name Bandwidth Profile Service Attribute need to be set carefully so that meeting [R150] does not cause the Performance Metric objectives of the SLS to be missed. Note if there is no need to apply the Bandwidth Profile Algorithm to egress Service Frames with a given Egress Equivalence Class Name, then this Egress Equivalence Class Name can be omitted from the list of x, y s. This obviates the need to specify parameter values for a Bandwidth Profile Flow that will never be used EVC EP Source MAC Address Limit Service Attribute 48 The value of the EVC EP Source MAC Address Limit Service Attribute is either Disabled or the pair N, τ where N is an integer 1 and τ is a time interval. When the value of the EVC EP Source MAC Address Limit Service Attribute = N, τ, the number of source MAC Addresses that can be used in ingress Service Frames is limited. This limit is applied by maintaining a list of maximum length N of source MAC addresses which are aged-out of the list if not seen in a time interval. If an ingress Service Frame arrives with a new source MAC address when the list is full, it is recommended that the Service Frame be discarded. In algorithmic terms, this can be stated as maintaining a list L where L = { A i, t i i = 1,2,, q N, A i = unicast MAC Address, t i = a time} The t i in each A i, t i is the most recent time that an ingress Service Frame arrived at the UNI that was mapped to the EVC EP and contained the source MAC address A i [D7] If Source MAC Address Limit = N, τ, then for a sequence of ingress Service Frames mapped to the EVC EP with Source MAC Addresses A j and arrival times at the UNI t j for j = 0,1,., the frames SHOULD be discarded per the logic of Figure 32 where L = at time t In MEF 10.3 [18] this is called Source MAC Address Limit Service Attribute. Page 104

115 Service Frame with source MACAddress A j arrives at time t j j 0 Remove all from L with t A, t i i t j i There exists A, t iˆ j iˆ such that A A L iˆ Yes Replace with A, t iˆ j iˆ A, t j L No Discard the Service Frame No L N Yes Add A, t j j to L Figure 32 Frame Discard for Source MAC Address Limit Note that [D7] does not mandate a specific implementation in the CEN. Any implementation that yields the same behavior as that of Figure 32 meets the requirement. For example, an implementation that removes A i, t i from the list at time t = t i + τ yields the same Service Frame discard behavior as that of Figure EVC EP Test MEG Service Attribute 49 The value of the EVC EP Test MEG Service Attribute is either Enabled or Disabled. [R151] When the value of the EVC EP Test MEG Service Attribute = Enabled, the CEN MUST instantiate a Test MEG MEP. When the value of the EVC EP Test MEG Service Attribute = Enabled, several parameter values need to be agreed upon by the Subscriber and the Service Provider. Further information can be found in MEF 30.1 [28] EVC EP Subscriber MEG MIP Service Attribute 50 The value of the EVC EP Subscriber MEG MIP Service Attribute is either Enabled or Disabled. [R152] When the value of the EVC EP Subscriber MEG MIP Service Attribute = Enabled, the CEN MUST instantiate a Subscriber Level MIP. 49 In [18] this is called Test MEG Service Attribute. 50 In MEF 10.3 [18] this is called Subscriber MEG MIP Service Attribute. Page 105

116 When the value of the EVC EP Subscriber MEG MIP Service Attribute = Enabled, several parameter values need to be agreed upon by the Subscriber and the Service Provider. Further information can be found in MEF 30.1 [28]. Editor Note 16: When MAEL is complete, it may provide some guidance on setting values for parameters related to the EVC EP Subscriber MEG MIP. Check MAEL when it is complete. Page 106

117 Multiple EVC Service Level Specification Service Attribute The value of the Multiple EVC Service Level Specification Service Attribute is a 3-tuple of the form ID, K G, A G where: ID is a string that identifies the instance of the Multiple EVC Service Level Specification Service Attribute K G is an integer A G is a percentage that is the Performance Metric Objective [R153] The value of ID MUST contain no more than 45 characters. 51 [R154] The value of ID MUST be a non-null RFC 2579 [12] DisplayString but not contain the characters 0x00 through 0x1f. [R155] All EVCs that belong to the Multiple EVC Group Availability Service Attribute via the value of the EVC Group Membership Service Attribute (Section 9.11) MUST be provided to a single Subscriber by a single Service Provider. [R156] All EVCs that belong to the Multiple EVC Group Availability Service Attribute via the value of the EVC Group Membership Service Attribute (Section 9.11) MUST NOT have the value of the EVC Service Level Specification Service Attribute (Section 9.10) = None. [R157] The values of the EVC Service Level Specification Service Attribute (Section 9.10) for the EVCs that belong to the Multiple EVC Group Availability Service Attribute via the value of the EVC Group Membership Service Attribute (Section 9.11) MUST have the same values for the pair t s, T. An example of the application of the Multiple EVC Group Availability Service Attribute is the Subscriber using one EVC as a backup for another EVC. Figure 33 shows an example commonly found in Mobile Backhaul. In this configuration the two EVCs backup each other to provide connectivity from the Cell Site to a Radio Area Network controller. The Mobile Operator uses routing protocols to select the EVC to carry all data other than the routing protocols. If the primary EVC fails, the Mobile Operator routers start sending data on the standby EVC. 51 The limit of 45 characters is intended to establish limits on field lengths in existing or future protocols that will carry the identifier. Page 107

118 Primary EVC Cell Site UNI 1 3 Standby EVC 2 4 RAN-NC UNI Service Provider CEN RAN-NC UNI UNI x EVC End Point EVC Figure 33 Example of the Multiple EVC SLS Service Attribute Consider an EVC whose value of the EVC Group Membership Service Attribute (Section 9.11) = a list of 3-tuples. Let the list contain the 3-tuple, MEGAOID, CoS_Name g, S g, with MEGAOID = ID, then H is defined as E, CoS_Name g, S g where E = the value of the EVC ID Service Attribute (Section 9.1) for the EVC. Let there be h instances of MEGAOID = ID among two or more EVCs and associated EVC Group Membership Service Attribute 3-tuples. For notational simplicity, index these instances as H q = E q, CoS_Name g q, S g q, q = 1,, h. In the example in Figure 33, each EVC offers a different Class of Service Name (Platinum and Gold). The value of the Multiple EVC Service Level Specification Service Attribute could yield: H 1 = Primary EVC, Platinum, { 1,2, 2,1 }, 0.5,7 H 2 = Standby EVC, Gold, { 3,4, 4,3 }, 0.75,9 K G = 1 A G = % When the Performance Metric for the Multiple EVC Service Level Specification (defined below) is met, the number of 30 second intervals during each 2400 hour period during which both EVCs Page 108

119 are experiencing high loss or in a Maintenance Interval is 288,000 ( ) = 2.88 out of 288,000. [R158] The value of the Multiple EVC Service Level Specification Service Attribute, MUST yield i {1, h} and j {1,, h} such that E i E j. [R158] means that h is at least 2 and at least two different EVCs are specified by the value of the Multiple EVC Service Level Specification Service Attribute. [R49] means that if E i = E j for i {1, h}, j {1,, h} and i j then at least one of the following is true: S i g S j g CoS_Name i g CoS_Name j g In other words, a given EVC can appear multiple times in H 1, H h, but E i, S g i, CoS_Name g i E j, S g j, CoS_Name g j for i {1,, h}, j {1,, h}, and i j. [R159] For all H q, q = 1,, h, the value of the EVC Service Level Specification Service Attribute (Section 9.10) for EVC E q MUST contain a 4-tuple in CN that contains CoS_Name g q. [R160] All 4-tuples specified in [R159] MUST contain the same value for t. Let t k and T l be as defined in Section For each H q, let AT i,j Tl,q denote Available Time for the ordered EVC EP pair i, j S g q and CoS_Name g q, as specified in Section Re- i,j call that if t k AT Tl,q, then tk does not intersect a Maintenance Interval and there has been good frame loss performance per the sliding window calculation. Define A Tl,q( t k ) = { 1 if t i,j k AT Tl,q for all i, j g Sq 0 otherwise Informally, A Tl,q( t k ) = 1 means that during the small time interval, none of the ordered EVC EP pairs have been impacted by a Maintenance Interval and all of the ordered EVC EP pairs have had good frame loss performance. Define A Tl ( t k ) = { 1 if A T l,q( t k ) K G q=1 0 otherwise h Page 109

120 Backup Primary 2725 Define W Tl = { t k t k T l } Note that W Tl. The Performance Metric for the Multiple EVC Service Level Specification Service Attribute, expressed as a percentage, is A Tl = 100 W Tl A Tl ( t k ) t k W Tl where W Tl is the number of elements of W Tl. [R161] The Multiple EVC Service Level Specification Service Attribute MUST define the Performance Metric for the Multiple EVC Service Level Specification as met over T l if and only if A Tl A G. Figure 34 shows the calculation of A Tl ( t k ) for the example of Figure 33. The value of the Per- formance Metric for this example is =88.24%. T l 1,2 2,1 3,4 4,3 2 =1 A Tl, t k A Tl t k i,j t k AT Tl, i,j t k AT Tl, Figure 34 Example of the Calculation of A Tl ( t k ) Page 110

121 Bandwidth Profile A Bandwidth Profile is a description of the temporal properties of a sequence of Service Frames at a UNI. A Bandwidth Profile consists of the set of traffic parameters applicable to a sequence of Service Frames. Associated with the Bandwidth Profile is an algorithm to determine Service Frame compliance with the specified parameters. All Bandwidth Profile Service Attributes (Sections 10.14, 10.15, 11.9, 11.10, 11.11, and 11.12) in this Technical Specification are based on the parameters and algorithm described in this section. A Bandwidth Profile is specified using the concepts of Bandwidth Profile Flow and Envelope. A Bandwidth Profile Flow is a set of Service Frames at a UNI that meet specific criteria. There are 6 types of Bandwidth Profile Flow per the following definitions: Ingress UNI Bandwidth Profile Flow: All ingress Service Frames at a UNI that are not discarded per [R77] with the possible exception of Service Frames discarded per [R112], [D1], [D2], [D7], [O2], or any of the conditions specified per [R16]. 52 Ingress EVC EP Bandwidth Profile Flow: All ingress Service Frames at a UNI that are mapped to a given EVC EP and that are not discarded per [R77] with the possible exception of Service Frames discarded per [R112], [D1], [D2], [D7], [O2], or any of the conditions specified per [R16]. 52 Ingress Class of Service Name Bandwidth Profile Flow: All ingress Service Frames at a UNI that have a given Class of Service Name, that are mapped to a given EVC EP, and that are not discarded per [R77] with the possible exception of Service Frames discarded per [R112], [D1], [D2], [D7], [O2], or any of the conditions specified per [R16]. 52 Egress UNI Bandwidth Profile Flow: All egress Service Frames at a UNI. Egress EVC EP Bandwidth Profile Flow: All egress Service Frames at a UNI that are mapped to a given EVC EP. Egress Equivalence Class Name Bandwidth Profile Flow: All egress Service Frames at a UNI that have a given Egress Equivalence Class Name and that map to a given EVC EP. 52 This document does not specify whether or not a Service Frame discarded per [R112], [D1], [D2], [D7], [O2], or any of the conditions specified per [R16] is in a Bandwidth Profile Flow. Page 111

122 Note that in some cases the two Bandwidth Profile Flow types can be equivalent, e.g., the Ingress UNI Bandwidth Profile Flow and the Ingress EVC EP Bandwidth Profile Flow are equivalent at a UNI with the value of the Subscriber UNI All to One Bundling Service Attribute = Enabled since there is only one EVC EP at the UNI and all Service Frames map to it (Section 10.11). Note that if a Service Frame is not in a Bandwidth Profile Flow, it will not be subjected to a Bandwidth Profile Algorithm (Section 13.2). For example, if Service Frame is discarded per [D7], it might not be in any Bandwidth Profile Flow and thus this Service Frame will not consume any tokens. An Envelope is a set that contains an integer n 1 number of Bandwidth Profile Flows that can share bandwidth resources that are represented by tokens. In an Envelope that contains n Bandwidth Profile Flows, each Bandwidth Profile Flow is assigned a unique rank between 1 (lowest) and n (highest). [R162] All Bandwidth Profile Flows in an Envelope MUST be of the same type. [R162] means: An Envelope contains Bandwidth Profile Flows with only ingress Service Frames or only egress Service Frames, An Ingress UNI Bandwidth Profile Flow will be in an Envelope by itself, and An Egress UNI Bandwidth Profile Flow will be in an Envelope by itself Multiple Envelopes containing Ingress EVC EP Bandwidth Profile Flows can co-exist at a UNI, each based on disjoint set of EVC EPs. Similarly multiple Envelopes containing Egress EVC EP Bandwidth Profile Flows can co-exist at a UNI, each based on disjoint set of EVC EPs. Multiple Envelopes containing Ingress Class of Service Name Bandwidth Profile Flows can coexist at a UNI. Similarly multiple Envelopes containing Egress Equivalence Class Name Bandwidth Profile Flows can co-exist at a UNI [R163] Each Bandwidth Profile Flow at a UNI MUST belong to exactly one Envelope. [R164] At a UNI, a Service Frame MUST be mapped to at most one Bandwidth Profile Flow. Table 31 shows the allowed combination of values for the various Ingress Bandwidth Profile relate Service Attributes for a given EVC EP that are a consequence of [R164]. Page 112

123 Ingress Bandwidth Profile Service Attributes Combination 1 Combination 2 Combination 3 Subscriber UNI Ingress Bandwidth Profile Parameters* Disabled Disabled EVC EP Ingress Bandwidth Profile Service At- Disabled Parameters* Disabled tribute EVC EP Class of Service Name Ingress Bandwidth Profile Service Attribute Disabled Disabled Parameters* is an abbreviation for CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F Parameters* or Disabled Table 31 Allowed Combinations of Ingress Bandwidth Profile Service Attributes Values for a Given EVC EP Table 32 shows the allowed combination of values for the various Egress Bandwidth Profile relate Service Attributes for a given EVC EP that are a consequence of [R164]. Egress Bandwidth Profile Service Attributes Combination 1 Combination 2 Combination 3 Subscriber UNI Egress Bandwidth Profile Service Attribute Parameters* Disabled Disabled EVC EP Egress Bandwidth Profile Service Attribute Disabled Parameters* Disabled Egress Bandwidth Profile per Egress Equivalence Parameters* or Disabled Disabled Class Name Disabled Parameters* is an abbreviation for CIR, CIR max, CBS, EIR, EIR max, EBS, CF, CM, ER, F Table 32 Allowed Combinations of Egress Bandwidth Profile Service Attributes Values for a Given EVC EP Note that a given Service Frame does not need to be mapped to a Bandwidth Profile Flow. When this is the case, it is said that the Service Frame is not subject to a Bandwidth Profile. When a Service Frame is mapped to a Bandwidth Profile Flow, [R163] and [R164] mean that this Service Frame is subject to exactly one Envelope and thus the Bandwidth Profile algorithm of Section 13.2 is applied to this Service Frame exactly once. As a consequence, at a UNI, each Service Frame mapped to a Bandwidth Profile Flow has exactly one color declaration. The Bandwidth Profile algorithm can be configured such that bandwidth that is not used by one Bandwidth Profile Flow can be reallocated to other Bandwidth Profile Flows in the same Envelope. The significance of the ranking of the Bandwidth Profile Flows is that it controls how the algorithm reallocates unused bandwidth from a given Bandwidth Profile Flow to another Bandwidth Profile Flow Bandwidth Profile Parameters The following subsections detail the parameters and related requirements for the parameters used in the Bandwidth Profile Algorithm (Section 13.2) Envelope Parameters The details of the Envelope Parameters are contained in Section Table 33 shows the parameters for each Envelope. Note that the descriptions in the table are informal. The precise role played by a given parameter is determined by the Bandwidth Profile Algorithm (Section 13.2). Page 113

124 Parameter Name Symbol Units Envelope ID RFC 2579 [12] DisplayString Envelope Coupling Flag Informal Description Identifies the Envelope CF 0 Integer Controls the conversion of unused Green tokens into Yellow tokens Table 33 Envelope Parameters Bandwidth Profile Flow Parameters Table 34 shows the parameters for each Bandwidth Profile Flow. Note that the descriptions in the table are informal. The precise role played by a given parameter is determined by the Bandwidth Profile Algorithm (Section 13.2). Parameter Name Symbol Units Informal Description Committed Information Rate which can be declared Green Defines the minimum rate of Service Frames CIR bits per second Maximum Committed Information Rate max bits per second Limits the rate of tokens added to the committed token bucket CIR Limits the maximum number of bytes available for a burst of Service Frames that will Committed Burst CBS bytes Size be declared Green Excess Information Defines the minimum rate of Service Frames EIR bits per second Rate Maximum Excess Information Rate EIR max bits per second Excess Burst Size EBS bytes Coupling Flag per Bandwidth Profile Flow CF integer Color Mode CM string Envelope and Rank Token Request Offset ER F [R165] CIR MUST be 0. <Envelope ID, integer 1> integer [R166] CIR max MUST be 0 Table 34 Bandwidth Profile Flow Parameters which can be declared Yellow Limits the rate of tokens added to the excess token bucket Limits the maximum number of bytes available for a burst of Service Frames that will be declared Yellow Determines if overflow Green tokens can be used as Yellow tokens Indicates whether the EVC EP Color Identifier of the Service Frame is considered by the Bandwidth Profile Algorithm Indicates the Envelope that the Bandwidth Profile Flow belongs to and the rank within the Envelope Adjusts the number of tokens requested for each Service Frame Page 114

125 [R167] If CIR > 0, then CBS MUST be greater than or equal to the lower bound for the Bandwidth Profile Flow in Table 35. Bandwidth Profile Flow Type Ingress UNI Bandwidth Profile Flow Egress UNI Bandwidth Profile Flow Ingress EVC EP Bandwidth Profile Flow Egress EVC EP Bandwidth Profile Flow Ingress Class of Service Name Bandwidth Profile Flow Egress Equivalence Class Name Bandwidth Profile Flow [R168] EIR MUST be 0. [R169] EIR max MUST be 0. Lower Bound on CBS and EBS Subscriber UNI Maximum Service Frame Size Service Attribute value EVC Maximum Service Frame Size Service Attribute value Table 35 Required Lower Bounds on CBS and EBS [R170] If EIR > 0, then EBS MUST be greater than or equal to the lower bound for the Bandwidth Profile Flow in Table 35. [R171] CF MUST have only one of two possible values, 0 or 1. [R172] If CF 0 = 1 for an Envelope, then CF MUST equal 0 for all Bandwidth Profile Flows mapped to the Envelope. [R173] CM MUST have only one of two possible values, color-blind or color-aware. [R174] The value of the rank in ER MUST be in the range 1,2,, n where n is the number of Bandwidth Profile Flows with the same Envelope ID value. [R175] The value of the rank in ER MUST NOT equal the rank of any of the other Bandwidth Profile Flows with the same Envelope ID value Bandwidth Profile Algorithm The Bandwidth Profile Algorithm applies to the Service Frames 53 in the Bandwidth Profile Flows that are mapped to a given Envelope. Operation of the Bandwidth Profile algorithm is governed by the parameters, CIR i i, CIR max, CBS i, EIR i i, EIR max, EBS i, CF i, CM i, ER i, F i for i = 1,2,, n where i identifies the rank and CF 0. The algorithm declares each Service Frame to 53 Consequently Data Service Frames, Layer 2 Control Service Frames and SOAM Service Frames can all be subject to a Bandwidth Profile. Page 115

126 be compliant or non-compliant relative to the Bandwidth Profile. The level of compliance is expressed as one of three colors, Green, Yellow, or Red. 54 The Bandwidth Profile algorithm is said to be in color-aware mode for Bandwidth Profile Flow i when the color of each Service Frame in Bandwidth Profile Flow i as determined by the EVC EP Color Map Service Attribute (Section 11.6) is taken into account in determining the level of compliance by the Bandwidth Profile algorithm. The Bandwidth Profile algorithm is said to be in color-blind mode for Bandwidth Profile Flow i when the color (if any) already associated with each Service Frame in a Bandwidth Profile Flow i is ignored by the Bandwidth Profile Algorithm. [R176] The Service Provider MUST be able to use color-blind mode for Bandwidth Profiles [O8] The Service Provider MAY use color-aware mode for Bandwidth Profiles The color mode of operation for Bandwidth Profile Flow i is determined using the parameter CM per [R173]. A token bucket model is used to describe the Bandwidth Profile Algorithm behavior. Each Bandwidth Profile Flow i has a committed token bucket that can contain up to CBS i tokens, and an excess token bucket that can contain up to EBS i tokens. Tokens for each bucket are sourced at a rate of up to CIR i and EIR i respectively (either or both of which can be 0 per [R165] and [R168]). Tokens for a Bandwidth Profile Flow may be made available to other buckets depending on the setting of the Coupling Flags (CF i, i = 1,2,, n) and what other Bandwidth Profile i Flows are mapped to the Envelope. Tokens flowing into a bucket are limited to CIR max and i EIR max respectively. Each Service Frame that maps to Bandwidth Profile Flow i will be declared Green, Yellow, or Red by the Bandwidth Profile Algorithm, depending on the arrival time of the Service Frame, the Color of the Service Frame (if any), and the number of tokens in the committed and excess token buckets. When a Service Frame for Bandwidth Profile Flow i is declared Green the number of tokens equal to the length of that Service Frame less the Token Request Offset, F i, is removed from the committed bucket for that Bandwidth Profile Flow. When a Service Frame for Bandwidth Profile Flow i is declared Yellow the number of tokens equal to the length of that Service Frame less the Token Request Offset, F i, is removed from the excess bucket for that Bandwidth Profile Flow. An informal description of the Bandwidth Profile algorithm for an Envelope is shown in Figure 35. In the figure, C i G (t) represents the number of Green tokens in the committed token bucket and C i Y (t) represents the number of Yellow tokens in the excess token bucket for the Bandwidth Profile Flow with rank i at time t, for i = 1,2,, n. The details of the calculation of C i G (t) and C i Y (t) are specified in MEF 41 [37]. A visual representation of the token flows within the Envelope is presented in Appendix D The categorization of a Service Frame does not imply any change to the content of the frame. Certain approaches to network implementation may mark frames internal to the CEN but such procedures are beyond the scope of this Technical Specification. Page 116

127 Service Frame of Length l j arrives at time t j for Bandwidth Profile Flow i j j 1 For i = n, n 1, 1 compute C i t j and C i t j CM i j == o or ind er i e Frame o or == reen A l j F i j C No i j t j Yes Declare the Service Frame Green i j i j C t j = C t j l j + F i j l j F i i j j C No t j Yes Figure 35 The Bandwidth Profile Algorithm Declare the Service Frame Yellow i j i j C t j = C t j l j + F i j Declare the Service Frame Red The Bandwidth Profile Algorithm is specified by reference to the Generic Token Sharing Algorithm of MEF 41 [37]. Two things are needed to do this: The relationship of the parameter values in this document to the values of the parameters in MEF 41 [37], and The specification of the Token Requests used in MEF 41. Table 36 shows the values of the General Parameters from Section 8.1 of MEF 41 [37]. MEF 45 [37] Parameter Value n Number of Bandwidth Profile Flows in the Envelope CF 0 CF 0 Table 36 Values of MEF 41 General Parameters Each MEF 41 TRF parameter (Section 8.2 of MEF 41[37]) takes on the value based a corresponding parameter value from this document as shown in Table 37. Page 117

128 MEF 45 [37] Parameter GTR i i GTR max GTV i YTR i i YTR max YTV i CF i Value CIR i 8 i CIR max 8 CBS i EIR i 8 i EIR max 8 EBS i CF i Table 37 Values of MEF 41 TRF Parameters for Rank i, i = 1, 2, n A Token Request, as defined in MEF 41 [37], corresponds to each Service Frame that arrives at the UNI and that is contained in Bandwidth Profile Flow with rank i per Table 38. Token Request Parameter l t c r Value L F i where L is the length in bytes of the Service Frame Arrival time of the Service Frame at the UNI If CM i = color-aware the color of the Service Frame per the value of the EVC EP Color Map Service Attribute (Section 11.6) i Table 38 Values for Token Requests for Bandwidth Profile Flow with Rank i, i = 1, 2, n Appendix D.3 describes examples of the use of the Token Request Offset, F i. [R177] If the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical, let l k, t k, c k, r k, k = 0,1, be the sequence of Token Requests constructed per Table 38 for all Bandwidth Profile Flows in the Envelope such that t k < t k+1, k = 0,1,. Then the color declaration for each Service Frame MUST equal the Color Determination for the corresponding Token Request using the algorithm of Section 10.2 in MEF 41 [37] with parameter values set as in Table 37. [R178] If the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Virtual, let s l, t l, l = 0,1,. be the subset of the output of the Subscriber UNI Virtual Frame Map (Section 10.3) such that the Service Frames s l, l = 0,1,2,. are in a Bandwidth Profile Flow in the Envelope, and let l k, t k, c k, r k, k = 0,1, be the sequence of Token Requests constructed per Table 38 with l k based on s l and t k based on t l. Then the color declaration for each Service Frame MUST equal the Color Determination for the corresponding Token Request using the algorithm of Section 10.2 in MEF 41 [37] with parameter values set as in Table 37. Page 118

129 Note that [R56] means that t k+1 t k, k = 0,1,. in [R178]. Note that this document does not mandate how the behavior specified by [R177] is achieved by the CEN. The network functionality could be distributed and configured in any way. Also note that, since the algorithm assumes perfect time precision and zero time required for calculations, it is impossible to achieve the exact behavior described by [R177]. A practical implementation needs to yield behavior "close" to the ideal behavior. Defining "close" is beyond the scope of this document. See Appendix D.4 for discussions of Bandwidth Profile implementation considerations Bandwidth Profile Algorithm With and Without Token Sharing When there is more than one Bandwidth Profile Flow mapped to an Envelope, it is possible that tokens that are not used by a given Bandwidth Profile Flow can be made available to another Bandwidth Profile Flow. In other words, tokens can be shared. In such a case, the values of the i i parameters CIR max and EIR max can be set such that a traffic in a higher rank Bandwidth Profile Flow cannot starve traffic in a lower rank Bandwidth Profile Flow. Appendix D.2 shows some examples of token sharing. When there is a single Bandwidth Profile Flow mapped to an Envelope, token sharing is not pos- 1 sible. Furthermore, if CIR max CIR 1 1, EIR max EIR 1 + (CF 1 CIR 1 ), and F 1 = 0, then the algorithm in Section 13.2 reduces to the algorithm of MEF 10.2 [17]. Page 119

130 Ethernet Service Framework The parameter values for the Service Attributes define the capabilities of an Ethernet Service. Service Attributes are described in Sections 8.1, 10, 11, and 12. For a particular Ethernet Service, there are three types of Service Attributes, those that apply to an EVC as described in Section 8.1, those that apply to a UNI as described in Section 10, those that apply to an EVC EP as described in Section 11. In addition, the Multiple EVC Service Level Specification Service Attribute described in Section 12 can be applied across multiple Ethernet Services. The UNI Service Attributes are listed in Table 39 along with their possible values. For a given Ethernet Service, a table like that of Table 39 needs to be specified for each UNI in the EVC associated with the service. Page 120

131 Service Attribute Subscriber UNI ID (Section 10.1) Subscriber UNI Instantiation (Section 10.2) Subscriber UNI Virtual Frame Map (Section 10.3) Subscriber UNI List of Physical Links (Section 10.4) Subscriber UNI Link Aggregation (Section 10.5) Subscriber UNI Port Conversation ID to Aggregation Link Map (Section 10.6) Subscriber UNI Service Frame Format (Section 10.7) Subscriber UNI Maximum Service Frame Size (Section 10.8) Subscriber UNI Maximum Number of EVC EPs (Section 10.9) Subscriber UNI Maximum Number of CE- VLAN IDs per EVC EP (Section 10.10) Subscriber UNI All to One Bundling (Section 10.11) Subscriber UNI Token Share (Section 10.12) Subscriber UNI Envelopes (Section 10.13) Subscriber UNI Ingress Bandwidth Profile (Section 10.14) Subscriber UNI Egress Bandwidth Profile (Section 10.15) Subscriber UNI Link OAM (Section 10.16) Subscriber UNI UNI MEG (Section 10.17) Subscriber UNI L2CP Address Set (Section 10.18) Subscriber UNI L2CP Peering (Section 10.19) Values A non-null RFC 2579 DisplayString no greater than 45 characters. Physical or Virtual. VMF or Not Applicable. Either a list of 3-tuples of the form pl, fs, ts or Not Applicable. None, 2-Link Active/Standby, All Active, Other, or Not Applicable. Either a Port Conversation ID to Aggregation Link Map as defined in IEEE Std 802.1AX 2014 [2] or Not Applicable. Ethernet MAC Frame conforming to Clause 3 of IEEE Std [4]. Integer Integer 1. Integer 1. Enabled or Disabled. Enabled or Disabled. A list of pairs of the form <x,y> where x is an Envelope ID value and y is the Envelope Coupling Flag value. Parameters or Disabled. Parameters or Disabled. Enabled or Disabled. Enabled or Disabled. As described in MEF 45 [38]. As described in MEF 45 [38]. Table 39 Subscriber UNI Service Attributes The EVC Service Attributes are listed in Table 40 along with their possible values. For a given Ethernet Service, a table like that of Table 40 needs to be specified for the EVC associated with the service. Page 121

132 2962 Attribute EVC ID (Section 9.1) EVC Type (Section 9.2) EVC EP List (Section 9.3) EVC Maximum Number of EVC EPs (Section 9.4) EVC Data Service Frame Disposition (Section 9.5) EVC CE-VLAN ID Preservation (Section 9.6) EVC CE-VLAN PCP Preservation (Section 9.7) EVC CE-VLAN DEI Preservation (Section 9.8) EVC List of Class of Service Names (Section 9.9) EVC Service Level Specification (Section 9.10) EVC Group Membership (Section 9.11) EVC Maximum Service Frame Size (Section 9.12) EVC Available MEG Level (Section 9.13) Values A non-null RFC 2579 DisplayString no greater than 45 characters. Point-to-Point, Multipoint-to-Multipoint, or Rooted-Multipoint. A list of EVC EP ID Service Attribute values. Integer 2. A 3-tuple of the form u, m, b where each element in the 3-tuple has the value Discard, Deliver Unconditionally, or Deliver Conditionally. Enabled or Disabled. Enabled or Disabled. Enabled or Disabled. A list of Class of Service Names. Performance Metric Objectives and parameters as described in Section A 3-tuple of the form MEGAOID, CoS_Name g, S g where MEGAOID is a string that is one of the values in an instance of the Multiple EVC Service Level Specification Service Attribute, CoS_Name g is an entry in the value of the EVC List of Class of Service Names Service Attribute that is not Discard, and S g is a subset of ordered EVC EP pairs constructed from the value of the EVC EP List Service Attribute. Integer Integer from 0 to 7 or None. Table 40 EVC Service Attributes The EVC EP Service Attributes are listed in Table 41 along with their possible parameter values. For a given Ethernet Service, a table like that of Table 41 needs to be specified for each EVC EP in the EVC associated with the service. Page 122

133 Attribute EVC EP ID (Section 11.1) EVC EP UNI (Section 11.2) EVC EP Role (Section 11.3) EVC EP Map (Section 11.4) EVC EP Ingress Class of Service Map (Section 11.5) EVC EP EVC EP Color Map (Section 11.6) EVC EP Egress Map (Section 11.7) EVC EP Egress Equivalence Class Map (Section 11.8) Ingress Bandwidth Profile Per EVC EP (Section 11.9) EVC EP Class of Service Name Ingress Bandwidth Profile (Section 11.10) EVC EP Egress Bandwidth Profile (Section 11.11) Egress Bandwidth Profile Per EVC EP Egress Equivalence Class Identifier (Section 11.11) EVC EP Source MAC Address Limit (Section 11.13) EVC EP Test MEG (Section 11.14) EVC EP Subscriber MEG MIP (Section 11.15) Values A non-null RFC 2579 DisplayString no greater than 45 characters. UNI ID value. Root or Leaf. List of one or more CE-VLAN ID values. A 3-tuple of the form F, M, P where F is a protocol field in the ingress Service Frame, M is a map that maps each possible value of the field F and the absence of the field F to a Class of Service Name and P is a map of Layer 2 Control Protocol types to Class of Service Names. A pair of the form <F, M> where F is a field in the ingress Service Frame and M is a mapping between each possible value of the field F and a Color. A set of mappings that determine the content of the C-Tag of an egress Service Frame. A 3-tuple of the form F, M, P where F is a protocol field in the egress Service Frame, M is a map that maps each possible value of the field F and the absence of the field F to an Egress Equivalence Class Name and P is a map of L2CP Protocol Identifier (per Section 6.2 of MEF 45 [38]) to Egress Equivalence Class Name. Parameters or Disabled. Parameters or Disabled. Parameters or Disabled. Parameters or Disabled. Disabled or the pair N, τ where N is an integer 1 and τ is a time interval. Enabled or Disabled. Enabled or Disabled. Table 41 EVC EP Service Attributes The Multiple EVC Group Availability Service Level Specification Service Attribute (Section 12) can be applied to multiple instances of Ethernet Service. The value for this Service Attribute is ID, K G, A G as described in Section 12. Page 123

134 References Editor Note 17: Need to check that all items in this list are referenced in the document. [1] IEEE Std 802.1AX 2008, IEEE Standard for Local and metropolitan area networks Link Aggregation, November [2] IEEE Std 802.1AX 2014, IEEE Standard for Local and metropolitan area networks Link Aggregation, December [3] IEEE Std 802.1Q 2014, IEEE Standard for Local and metropolitan area networks-- Bridges and Bridged Networks, 3 November [4] IEEE Std , IEEE Standard for Ethernet, 3 September [5] IEEE Std , IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, 24 July [6] International Telecommunication Union, Recommendation G.8262/Y.1362, Timing characteristics of synchronous Ethernet equipment slave clock, January [7] International Telecommunication Union, Recommendation G.8264/Y.1364, Distribution of timing information through packet networks, May [8] International Telecommunication Union, Recommendation Y.1563, Ethernet frame transfer and availability performance, [9] International Telecommunication Union, Recommendation Y.1564, Ethernet service activation test methodology, May [10] Internet Engineering Task Force, RFC Key words for use in RFCs to Indicate Requirement Levels, March [11] Internet Engineering Task Force, RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December [12] Internet Engineering Task Force, RFC Textual Conventions for SMIv2, April [13] Internet Engineering Task Force, RFC 3393, IP Packet Delay Variation Metric for IP Performance Metric (IPPM), November [14] MEF Forum, MEF 4, Metro Ethernet Network Architecture Framework - Part 1: Generic Framework, May [15] MEF Forum, MEF 6.2, Ethernet Services Definitions - Phase 3, August [16] MEF Forum, MEF 7.3, Carrier Ethernet Information Model, February Page 124

135 [17] MEF Forum, MEF 10.2, Ethernet Services Attributes Phase 2, October [18] MEF Forum, MEF 10.3, Ethernet Services Attributes Phase 3, October [19] MEF Forum, MEF , Composite Performance Metric (CPM) Amendment to MEF 10.3, February [20] MEF Forum, MEF , Amendment to MEF UNI Resiliency Enhancement, October [21] MEF Forum, MEF 12.2, Carrier Ethernet Network Architecture Framework Part 2: Ethernet Services Layer, May [22] MEF Forum, MEF 17, Service OAM Framework and Requirements Phase 1, April [23] MEF Forum, MEF 20, User Network Interface (UNI) Type 2 Implementation Agreement, July [24] MEF Forum, MEF 22.2, Mobile Backhaul Phase 3, January [25] MEF Forum, MEF 23.2, Carrier Ethernet Class of Service Phase 3, August [26] MEF Forum, MEF , Models for Bandwidth Profiles with Token Sharing Amendment to MEF 23.2,???? [27] MEF Forum, MEF 26.2, External Network Network Interfaces (ENNI) and Operator Service Attributes, August [28] MEF Forum, MEF 30.1, Service OAM Fault Management Implementation Agreement: Phase 2, April [29] MEF Forum, MEF , Amendment to MEF 30.1 Correction to Requirement, April [30] MEF Forum, MEF 31, Service OAM Fault Management Definition of Managed Objects, January [31] MEF Forum, MEF , Amendment to Service OAM SNMP MIB for Fault Management, January [32] MEF Forum, MEF 35.1, Service OAM Performance Monitoring Implementation Agreement, May [33] MEF Forum, MEF 36.1, Service OAM SNMP MIB for Performance Monitoring, April [34] MEF Forum, MEF 38, Service OAM Fault Management YANG Modules, April Page 125

136 [35] MEF Forum, MEF 39, Service OAM Performance Monitoring YANG Module, April [36] MEF Forum, MEF 40, UNI and EVC Definition of Managed Objects, April [37] MEF Forum, MEF 41, Generic Token Bucket Algorithm, October [38] MEF Forum, MEF 45, Multi-CEN L2CP, August Page 126

137 3040 Appendix A Examples (Informative) This appendix contains examples of some of the attributes specified in this Technical Specification. They are for illustrative purposes only. In the event of a conflict between the material in this appendix and the main body of this text, the material in the main body is controlling. A.1 EVC CE-VLAN ID Preservation Service Attribute The following is a list of examples covering the EVC CE-VLAN ID Preservation Service Attribute for both the value of the EVC CE-VLAN ID Preservation Service Attribute = Enabled and Disabled (Section 9.6). A.1.1 EVC CE-VLAN ID Preservation Service Attribute Value = Enabled Figure 36 shows an example when the value of the Subscriber UNI All to One Bundling Service Attribute (Section 10.11) = Enabled. Ingress Frames Frame A Untagged Frame B Priority Tagged Frame C VLAN Tagged 10 Frame D VLAN Tagged 12 Egress Frames Frame E Untagged Frame F Priority Tagged Frame G VLAN Tagged 10 Frame H VLAN Tagged 12 A EVC 1 Ingress Frames Frame E Untagged Frame F Priority Tagged Frame G VLAN Tagged 10 Frame H VLAN Tagged 12 B Egress Frames Frame A Untagged Frame B Priority Tagged Frame C VLAN Tagged 10 Frame D VLAN Tagged EVC End Point Map EVC End Point A EVC End Point Map EVC End Point B Figure 36 Example 1: Subscriber UNI All to One Bundling Service Attribute Value = Enabled Figure 37 shows an example when the value of the Subscriber UNI Maximum Number of CE- VLAN IDs per EVC EP Service Attribute (Section 10.10) Page 127

138 Ingress Frames Frame A Untagged Frame B Priority Tagged Frame C VLAN Tagged 20 Frame D VLAN Tagged 22 Frame E VLAN Tagged 30 C EVC 2 Ingress Frames Frame F Untagged Frame G Priority Tagged E Frame H VLAN Tagged 20 Frame I VLAN Tagged 22 Frame J VLAN Tagged 30 Egress Frames Frame F? Frame G? Frame H? Frame I VLAN Tagged 22 Frame J VLAN Tagged 30 D EVC 3 Egress Frames F Frame A? Frame B? Frame C? Frame D VLAN Tagged 22 Frame E VLAN Tagged EVC End Point Maps EVC End Point C EVC End Point D EVC End Point Maps EVC End Point E EVC End Point F 0 30? indicates untagged, priority tagged or VLAN Tagged with VLAN = 20 or 22 Figure 37 Example 2: Subscriber UNI Maximum Number of CE-VLAN IDs per EVC EP Service Attribute Value 2 A.1.2 EVC CE-VLAN ID Preservation Service Attribute Value = Disabled Figure 41, Figure 39, Figure 40, and Figure 41 show examples when the value of the EVC CE- VLAN ID Preservation Service Attribute (Section 9.6) = Disabled. Ingress Frames Frame A Untagged Frame B Priority Tagged Frame C VLAN Tagged 40 Frame D VLAN Tagged 42 Egress Frames Frame E Untagged Frame F Untagged Frame G Untagged EVC End Point Map EVC End Point G 0 40 G EVC Ingress Frames Frame E Untagged Frame F Priority Tagged Frame G VLAN Tagged 44 Frame H VLAN Tagged 46 H Egress Frames Frame A Untagged Frame B Untagged Frame C Untagged EVC End Point Map EVC End Point H Figure 38 Example 3: EVC CE-VLAN ID Preservation Service Attribute Value = Disabled 0 44 Page 128

139 Ingress Frames Frame A Untagged Frame B Priority Tagged Frame C VLAN Tagged 50 Frame D VLAN Tagged 52 Egress Frames Frame H Untagged I EVC 5 Ingress Frames Frame E Untagged Frame F Priority Tagged Frame G VLAN Tagged 54 Frame H VLAN Tagged 56 J Egress Frames Frame A VLAN Tagged 56 Frame B VLAN Tagged 56 Frame C VLAN Tagged EVC End Point Map EVC End Point I 0 50 EVC End Point Map EVC End Point J Figure 39 Example 4: EVC CE-VLAN ID Preservation Service Attribute Value = Disabled 56 Ingress Frames Frame A Untagged Frame B Priority Tagged Frame C VLAN Tagged 60 Frame D VLAN Tagged 62 Egress Frames (UNI I) Frame H Untagged K EVC 6 Ingress Frames Frame E Untagged Frame F Priority Tagged Frame G VLAN Tagged 64 Frame H VLAN Tagged 60 L Egress Frames (UNI J) Frame A VLAN Tagged 60 Frame B VLAN Tagged 60 Frame C VLAN Tagged EVC End Point Map EVC End Point K 0 EVC End Point Map EVC End Point L 60 Figure 40 Example 5: EVC CE-VLAN ID Preservation Service Attribute Value = Disabled 60 Ingress Frames Frame A Untagged Frame B Priority Tagged Frame C VLAN Tagged 70 Frame D VLAN Tagged 72 M EVC 7 Ingress Frames Frame E Untagged Frame F Priority Tagged NFrame G VLAN Tagged 74 Frame H VLAN Tagged 76 Egress Frames Frame H VLAN Tagged 72 Egress Frames Frame D VLAN Tagged EVC End Point Map EVC End Point M 72 EVC End Point Map EVC End Point N Figure 41 Example 6: EVC CE-VLAN ID Preservation Service Attribute Value = Disabled 76 Page 129

140 A.2 Examples of the Use of the EVC EP Map and EVCs This section presents examples of the use of EVCs and the EVC EP Map Service Attribute. It is intended to clarify the concepts and present likely deployment scenarios. A.2.1 Untagged UNIs In connecting branch enterprise locations to a hub enterprise location, it is desirable to make the configuration of the branch SEs simple. A similar objective applies to providing access to higher layer services, e.g., Internet Access, where the configuration of the SE at the sites accessing the service should be kept simple. Figure 42 shows an example of 3 UNIs (A, B, and C) where SEs only capable of handling Untagged Service Frames are attached. The EVC EP Map Service Attribute values are shown for each EVC EP. UNI A 2 1 Service Provider CEN UNI D UNI B 6 UNI C UNI x EVC End Point EVC EVC EP Map Service Attribute Values Figure 42 Untagged UNIs Consider an ingress Untagged Service Frame at UNI A. It will be mapped to EVC EP 2 and delivered to EVC EP 1 located at UNI D. At UNI D, it will become a VLAN Tagged egress Service Frame with VLAN ID 65. An ingress VLAN Tagged Service Frame at UNI D with VLAN ID 65 will be mapped to EVC EP 1 and delivered to EVC EP 2 located ate UNI A. At UNI A, it will become an egress Untagged (Section 8.4) Service Frame. Page 130

141 Editor Note 18: The following paragraph and table have been added to address the fact the 0 is the CE-VLAN ID value Untagged Service Frames. Another way to support Untagged Service Frames at the branch locations is to use the EVC EP Map Service Attribute values in Table 42. In the case of Figure 42, an ingress VLAN Tagged Service Frame at UNI B with CE-VLAN ID value = 37 will be delivered to UNI D. In the case of Table 42, such a frame will be discarded. A.2.2 Use of Rooted-Multipoint EVC EVC EP Map Service Attribute Values Table 42 Alternative Approach to Untagged UNIs An example of the use of the Rooted-Multipoint EVC is shown in Figure 43. A higher layer service is being provided via UNI D to three different customers at UNIs A, B, and C. By using a Rooted-Multipoint EVC, all three customers can be reached by the higher layer service provider at UNI D using a single EVC. Each customer s SE can only send to the higher layer service SE thus keeping each customer from seeing other customers sourced traffic. Compared with the example shown in Figure 42, this can save a large number of Point-to-Point EVCs when there are a large number of customers. Note that the SEs do not necessarily have to send and receive C- Tagged Service Frames. In particular, the SEs at UNIs A and C do not need to send or receive C- Tagged Service Frames in this example. Page 131

142 UNI A 2 Leaf UNI D Root Service Provider CEN Leaf 1 3 UNI B 4 Leaf UNI C UNI x EVC End Point EVC EVC EP Map Service Attribute Values Figure 43 Use of a Rooted-Multipoint EVC A.2.3 Redundant Higher Layer Service Access The example shown in Figure 44 illustrates the use of Service Multiplexing and Multipoint-to- Multipoint EVCs to provide redundant access to higher layer services. A Multipoint-to- Multipoint EVC is used for each customer of the higher layer service. Higher layer service routers are attached to two UNIs (C and D in the example) in each such EVC. Routing protocols running among the two higher layer service routers and the customer router allow the customer to access the higher layer service in a redundant fashion. Page 132

143 UNI C 5 2 UNI D Service Provider CEN UNI A 6 UNI B UNI x EVC End Point EVC EVC EP Map Service Attribute Values Figure 44 Redundant Higher Layer Service Access A.3 Examples of Availability Metrics for Multipoint EVCs The Performance Metric definitions for Multipoint EVCs provide a great deal of flexibility. This section provides examples on how the subset of EVC EPs in the EVC can be used to define UNIoriented Performance Metrics (Section A.3.1) and EVC-oriented Performance Metrics (Section A.3.2). The Availability Performance Metric is used for these examples. Both examples use the Multipoint EVC depicted in Figure 45 where the EVC EPs are not shown for simplicity. There are two Class of Service Names supported on the EVC, namely CoS Name 1 and CoS Name 2. The important traffic paths for each Class of Service Name have been agreed to by Subscriber and the Service Provider as shown in the figure. Page 133

144 UNI C UNI A UNI E UNI B UNI D UNI EVC End Point EVC Important paths for CoS Name Important paths for CoS Name 1 Figure 45 Multipoint EVC Example A.3.1 UNI-oriented Availability Example In this case, an Availability Performance Metric is defined for each UNI for each Class of Service Name. The Performance Metric is based on the ability to communicate from the UNI in question and the other UNIs identified by the important traffic flows. Define the following subsets of ordered EVC EP pairs where EVC EP X is located at UNI X for X = A, B, C, D, E: S A,1 = { A, B, A, C, A, D, A, E } S B,1 = { B, A, B, C, B, D, B, E } S C,1 = { C, A, C, B } S D,1 = { D, A, D, B } S E,1 = { E, A, E, B } S A,2 = { A, C, A, E } S C,2 = { C, A, C, E } S E,2 = { E, A, E, C } For this example, assume that T l, t, C, and n, are used for all availability Performance Metrics. S Then using the definition in Section , A A,1 Tl can be viewed as the availability of UNI A for Class of Service Name 1 and this reflects the availability from UNI A to the other UNIs identi- S fied by the important traffic flows. Similarly, A C,2 Tl can be viewed as the availability of UNI C for Page 134

145 Class of Service Name 2. Thus, the availability for each UNI for each Class of Service Name can be defined by selecting the appropriate subset of EVC EP pairs. A.3.2 EVC-oriented Availability Example In this case an Availability Performance Metric is defined for each Class of Service Name supported by the EVC. Define the following subsets of ordered EVC EP pairs where EVC EP X is located at UNI X for X = A, B, C, D, E: S 1 = { A, B, B, A, A, C, C, A, A, D, D, A, A, E, E, A, B, C, C, B, B, D, D, B, B, E, E, B } S 2 = { A, C, C, A, A, E, E, A, C, E, E, C } For this example, assume that T l, t, C, and n, are used for both availability Performance Met- S rics. Then using the definition in Section , A 1 Tl can be viewed as the availability of Class of 3143 S Service Name 1 on the EVC and A 2 Tl can be viewed as the availability of Class of Service Name on the EVC Page 135

146 3146 Appendix B Traffic Shaping Example (Informative) Shaping is a procedure to reduce the burstiness of traffic. When done in the SE it is meant to increase the level of Bandwidth Profile compliance (Sections 10.14, 11.9, and 11.10). A shaper is defined by a set of parameters. Those parameters should be chosen to ensure that the delay introduced by shaping function is bounded within the acceptable limits and that the traffic dropped at the shaper is kept to a minimum. The example in this appendix assumes a single Bandwidth Profile Flow of ingress Service Frames that is the only Bandwidth Profile Flow mapped to the Envelope. Two example algorithms are presented that together describe a shaper implementation in the SE. These are the Periodic Algorithm shown in Figure 46 and the New Frame Algorithm shown in Figure 47. In the New Frame Algorithm, a limited number of Yellow frames can be placed in the shaper buffer 55 (and subsequent Yellow frames will be dropped if required). This controls the delay that may be experienced by Green frames due to the presence of Yellow frames. There may be Yellow frames ahead of a Green frame in the transmission buffer, but that will typically not add significant delay. The following parameters are used in the example algorithms: CIR = the shaping rate of Green frames (average output rate of the shaper), CBS = the shaping burst size of Green frames (maximum output burst of the shaper), EIR = the shaping rate of Yellow frames (average output rate of the shaper), EBS = the shaping burst of Yellow frames (maximum output burst of the shaper), CF = the Coupling Flag that controls whether tokens that overflow the Committed token bucket are added to the Excess token bucket, CM = the Color Mode can be either Color_Blind or Color_Aware and controls whether the color of a frame is considered in determining when to transfer it from the shaper buffer to the transmission buffer, SBL = the Shaper Buffer Limit is the depth of the shaper buffer (in bytes) above which no new frames will be placed in the shaper buffer, YBL = the Yellow Buffer Limit is the depth of the shaper buffer (in bytes) above which no new yellow frames will be placed in the shaper buffer, and t = the time interval between the executions of the Periodic Algorithm. 55 Note that we differentiate between the shaper buffer, and the transmission buffer (outgoing link queue). Frames taken from the head of the shaper buffer are queued in the transmission buffer for transmission at line rate. Page 136

147 F = the token request offset that is subtracted from the length of the frame when tokens are deducted upon sending the frame to the transmission buffer The CM parameter only affects whether the color of a frame is considered when removing that frame from the shaper buffer. Whether the color of a frame is considered when placing that frame into the shaper buffer is controlled by YBL and SBL. If YBL = SBL then yellow and green frames receive identical treatment when determining whether to place the frame in the shaper buffer (i.e. color blind behavior), and otherwise the color affects whether to place the frame in the shaper buffer (i.e. color aware behavior). YBL is the maximum burst of yellow frames that can be placed in the shaper buffer. SBL is the maximum burst of all frames (green and yellow) that can be placed in the shaper buffer. When the shaper buffer is empty, this means at least SBL YBL green frames in a burst can be placed in the shaper buffer. Typically the shaper buffer limits are configured such that SBL YBL CBS, which means the shaper accepts larger bursts of green frames at its input and generates smaller bursts of green frames at its output. The maximum delay that can be experienced by a green frame is SBL divided by CIR, provided that CIR is the minimum rate at which frame are moved from the shaper buffer to the transmission buffer. This will be the case as long as either CF = 1 (so tokens overflowing the Committed token bucket are added to the Excess token bucket) or EIR CIR. Yellow frames arriving at the shaper will only be transferred to the transmission buffer using yellow tokens. Green frames arriving at the shaper will be transferred to the transmission buffer using green tokens when they are available, or yellow tokens when no green tokens are available. The following notation is used in the example algorithms where t represents the time that the algorithm is run: B(t) = the instantaneous shaper buffer occupancy in bytes, C(t) = the instantaneous value of the tokens in the Committed token bucket with C(0) = CBS, E(t) = the instantaneous value of the tokens in the Excess token bucket with E(0) = EBS, L = the length of the frame at the head of the shaper buffer, LNF = the length of the newly-arrived frame, CNF = the color of the newly arrived frame, and CHF = color of the frame at the head of the shaper buffer. Page 137

148 The Periodic Algorithm is shown in Figure 46. It is executed every t time units and transfers frames to the transmission buffer in times between the arrival of new frames when sufficient tokens become available. C(t)=min(CBS,(C(t)+(CIR/8)* t)); // Update green token count O(t)=max(0,(C(t)+(CIR/8)* t CBS)); // Compute overflow green tokens E(t)=min(EBS,(E(t)+(EIR/8)* t+cf*o(t))); // Update Yellow token count while(((l<=c(t))&&(b(t)>0)&&(chf==green CM=Color_Blind)) ((L<=E(t))&&(B(t)>0))) { if((l<=c(t))&&(b(t)>0)&&(chf==green CM=Color_Blind)) { //Transmit using Green tokens C(t)=C(t) (L-F); B(t)=B(t) L; send the frame at the head of the shaper buffer to the transmission buffer; } else { //Transmit using Yellow tokens E(t)=E(t) (L-F); B(t)=B(t) L; Send the frame at the head of the shaper buffer to the transmission buffer; } } Figure 46 Periodic Algorithm The New Frame Algorithm is shown in Figure 47. It is executed each time a new frame arrives at the shaper. For simplicity it is assumed that CIR > 0 and at least one of the following is true: CF = 1 EIR > 0. These assumptions mean: A Yellow frame with length less than EBS will not get stuck in the shaper buffer because enough Yellow tokens can be accumulated to move it to the transmission buffer via the Periodic Algorithm. A Green frame with length less than max(cbs, EBS) will not get stuck in the shaper buffer because enough tokens, either Green or Yellow, can be accumulated to move it to the transmission buffer via the Periodic Algorithm. Page 138

149 if(b(t)==0) // If shaper buffer is empty { if((cnf==yellow)&&(cm=color_aware)) { if((lnf-f)<=e(t)) { //Transmit using Yellow tokens E(t)=E(t) (LNF-F); send new frame to transmission buffer; } else if((b(t)+lnf<=ybl)&&((lnf-f)<=ebs))//b(t)=0 so only need LNF { //Room in the shaper buffer for the new frame and it is //possible to accumlate enough Yellow tokens to transmit //the frame in the Periodic Algorithm place new frame in shaper buffer; B(t) = B(t) + LNF; //B(t)=0 so could use B(t)=LNF } else { discard new frame; } } else // New frame is Green or shaper is configured to be Color_Blind { if((lnf-f)<=c(t)) { //Transmit using Green tokens C(t)=C(t) (LNF-F); send new frame to transmission buffer; } else if((lnf-f)<=e(t)) { //Transmit using yellow tokens E(t)=E(t) (LNF-F); send new fame to transmission buffer; } else if((b(t)+lnf<=sbl)&&((lnf-f)<=max(cbs,ebs))) { //Room in the shaper buffer for the new frame and it is //possible to accumlate enough tokens to transmit //the frame in the Periodic Algorithm place new frame in shaper buffer; B(t)=B(t)+LNF; //B(t)=0 so could use B(t)=LNF } else { discard new frame; } } } else // shaper buffer is not empty { if((cnf==yellow)&&(cm=color_aware)) { if((b(t)+lnf<=ybl)&&((lnf-f)<=ebs)) Page 139

150 { //Room in the shaper buffer for the new frame and it is //possible to accumlate enough Yellow tokens to transmit //the frame in the Periodic Algorithm place new frame in shaper buffer; B(t) = B(t) + LNF; } else { discard the new frame; } } else if((b(t)+lnf<=sbl)&&((lnf-f)<=max(cbs,ebs))) { //Room in the shaper buffer for the new frame and it is //possible to accumlate enough tokens to transmit //the frame in the Periodic Algorithm place new frame in shaper buffer; B(t)=B(t)+LNF; } else { discard the new frame; } } Figure 47 New Frame Algorithm Page 140

151 Frame Packet 3331 Appendix C Effect of Service Frame Overhead (Informative) This Appendix assumes that the value of the Subscriber UNI Instantiation Service Attribute (Section 10.2) = Physical. Figure 48 is a simplified version of Figure 3 1 in IEEE Std [4] which shows the format of the IEEE Std Packet. Because UNIs specified in this document do not run in half duplex mode, the Extension Field is always zero length and not shown in the figure. As can be seen from Figure 48 the Service Frame is exactly the IEEE Std Frame. IEEE Std Packets are separated by an Inter-Packet gap of at least 96 bit times (12 bytes). Thus the minimum separation between Service Frames transmitted across a UNI is 20 bytes bytes Inter-Packet Gap 7 bytes Preamble 1 byte Start Frame Delimiter 6 bytes Destination Address 6 bytes Source Address 2 bytes Length/Type Variable Length MAC Client Data & Pad 4 bytes Frame Check Sequence Figure 48 IEEE Std Packet Format (simplified) ITU Y.1564 [9] defines Information Rate as the average bit rate of Service Frames at the measurement point starting with the first MAC address bit and ending with the last FCS bit. In the context of this document, the measurement point is the UNI. To calculate the Information Rate of a group of Service Frames, take the total number of Service Frame bits (the sum of the lengths of each Service Frame in bits from Figure 48) divided by the amount of time from the first bit in the first Service Frame to the last bit in the last Service Frame plus the amount of time for 160 more bits (minimum Inter-Packet gap, preamble, and start of frame delimiter). Let S be the sum of the Service Frame bits in bits, let r be the UNI Line Rate in bits per second, let T 1 be the time when the first bit of the first Service Frame arrives at the UNI, and let T 2 be the time when the last bit of the last Service Frame arrives at the UNI. Then Information Rate for a group of Service Frames = S T 2 T r Page 141

152 Ratio For a given Service Frame size, the Information Rate is maximized when the Service Frames in the group are back to back, i.e., the Service Frames are separated by 160 bits. For n back to back Service Frames each with length x bits, T 2 T 1 = nx + (n 1)160 r and Information Rate for n back to back Service Frames each with length x bits = nx nx + (n 1)160 r r x = ( x ) r Figure 49 shows the ratio of the Information Rate to UNI Line Rate as a function of Service Frame size for a group of fixed length, back to back Service Frames Service Frame Size (bytes) 2000 Figure 49 Ratio of Information Rate to UNI Line Rate for Back to Back Service Frames Figure 49 has implications on the behavior of the Bandwidth Profile Algorithm of Section When that algorithm is applied to a sequence of Service Frames, it deducts tokens from a token bucket based on the number of bytes in each Service Frame. Thus it is possible to pick a value of CIR i that is less than the UNI Line Rate but results (perhaps after a transient period to allow the token bucket to accumulate tokens) in all Service Frames being declared Green. For example, if all Service Frames had lengths of no more than 100 bytes, then choosing CIR i to be.85 of the UNI Line Rate would yield this behavior. ITU Y.1564 [9] defines Utilized Line Rate as the average bit rate of the Ethernet line at the measurement point, including the bits a) allocable to the minimum-duration period of each Inter- Packet gap (but not the number of bits allocable to the part of each Inter-Packet gap longer than the minimum), b) in the preamble, c) in the start of frame delimiter and d) in the Ethernet Service Frame starting with the first MAC address bit and ending with the last FCS bit. In the context of this document, the measurement point is the UNI. Page 142

153 To calculate the Utilized Line Rate of a group of n Packets, take the total number of Packet bits (the length of each Packet in bits from Figure 48) plus n times the minimum Inter-Packet gap divided by the amount of time from the first bit in the first Packet to the last bit in the last Packet plus the time for minimum Inter-Packet gap (96 bits). Let P be the sum of the Packet bits in bits, let r be the UNI Line Rate in bits per second, let T 1 be the time when the first bit of the first Packet arrives at the UNI, and let T 2 be the time when the last bit of the last Packet arrives at the UNI. In equation form: Utilized Line Rate for a group of n Packets = P + n96 T 2 T r 3385 When the n Packets are back to back, T 2 T 1 = P + (n 1)96 r and the Utilized Line Rate for a group of back to back Packets is equal to the UNI Line Rate. Consequently, Information Rate for n back to back Service Frames each with length x bits x = ( ) Utilized Line Rate for n back to back Packets. x Page 143

154 3389 Appendix D Bandwidth Profiles (Informative) D.1 Visual Representation of the Bandwidth Profile Token Flows Figure 50 shows a conceptual diagram of the Bandwidth Profile Algorithm with three Bandwidth Profile Flows The green and yellow trapezoid icons labeled CBS i and EBS i represent the Committed and Excess token buckets for each Bandwidth Profile Flow. The green and yellow flag-shaped icons labeled CIR i or EIR i represent a token source flowing into each bucket at the rate specified by the Bandwidth Profile. i i The red funnel-shaped icons labeled CIR max and EIR max represent the limits on how fast tokens can be added to a token bucket. The dashed arrows show possible token paths. An arrow that originates at a funnel i i represents tokens that don t enter a token bucket due to CIR max or EIR max. An arrow that originates at a trapezoid represent tokens that overflow the bucket when the number of tokens in the bucket reaches the capacity (CBS i or EBS i ). The elipses labeled CF i represent decision points in the path of the tokens that are controlled by the Coupling Flag. The X s represent points at which tokens are discarded (i.e., not added to the token count for any of the buckets). Page 144

155 C 3 E 3 C 3 E 3 CBS 3 0 CF 3 1 EBS 3 + C C 2 2 E 2 C C 22 E 22 CBS 2 0 CF 2 1 EBS 2 + C C 11 E 1 C 1 E 1 CBS 1 CF CF EBS 1 X X Figure 50 Bandwidth Profile Token Flows D.2 Bandwidth Profile Use Cases This sub-section contains some Bandwidth Profile use cases. Additional Bandwidth Profile use cases can be found in MEF [26] D.2.1 Sharing Excess Bandwidth In this use case, three Bandwidth Profile Flows are included in an Envelope with each Bandwidth Profile Flow having a dedicated CIR i. Overflow Green tokens for each Bandwidth Profile Flow are sent to the Excess token bucket for that Bandwidth Profile Flow. Overflow Yellow tokens are shared with lower ranked Bandwidth Profile Flows. In this case, the amount of bandwidth of Qualified Service Frames for each Bandwidth Profile Flow is bounded by each CIR i and overflows of Green tokens are available for frames that have no SLS commitment. The configuration of this example is CF 0 = 0, CF i = 1, i = 1,2,3. Figure 51 shows the token paths for this configuration. Page 145

156 C 3 E 3 C 3 E 3 CBS 3 1 EBS 3 + C C 2 2 E 2 C C 22 E 22 CBS 2 1 EBS 2 + C C 11 E 1 C 1 E 1 CBS 1 1 EBS 1 X Figure 51 Bandwidth Profile Algorithm for Sharing Excess Bandwidth D.2.2 Uncoupled Bandwidth Sharing In this use case, three Bandwidth Profile Flows are included in an Envelope. The Bandwidth Profile Flows share CIR env committed bandwidth and EIR env excess bandwidth. 56 Green tokens are not converted to Yellow tokens. The configuration of this example is CF 0 = 0, CF i = 0, i = 1,2,3, CIR 1 = CIR 2 = EIR 1 = EIR 2 = 0, CIR 3 = CIR env, and EIR 3 = EIR env. Figure 52 shows the token paths for this configuration. 56 CIR env and EIR env are not Bandwidth Profile parameters defined in Section 13. CIR env represents the number of bits per second of total committed bandwidth shared by the three Bandwidth Profile Flows. EIR env represents the number of bits per second of total excess bandwidth shared by the three Bandwidth Profile Flows. Page 146

157 C n E n C 3 E 3 CBS 3 0 EBS 3 + C 2 C C 22 E 22 CBS 2 0 EBS 2 + C C 11 C 1 E 1 CBS 1 0 EBS 1 X X Figure 52 Bandwidth Profile Algorithm for Uncoupled Bandwidth Sharing The amount of bandwidth of Qualified Service Frames range from 0 to CIR env for each Band width Profile Flow. CIR max, CIR max, and CIR max can be used to limit committed bandwidth for Bandwidth Profile Flows 3, 2, and 1. Similarly, EIR max, EIR max, and EIR max can be used to limit excess bandwidth for Bandwidth Profile Flows 3, 2, and 1. A similar but different use case is to make CIR 1 and CIR 2 positive in order to ensure that Bandwidth Profile Flows 1 and 2 are not starved for committed bandwidth by higher ranked Bandwidth Profile Flows. Similarly, EIR 1 and EIR 2 can be used to ensure that Bandwidth Profile Flows 1 and 2 are not starved for excess bandwidth by higher ranked Bandwidth Profile Flows. D.2.3 Sharing Bandwidth among Class of Service Names In this use case, CoS Labels H, M, and L share CIR env bandwidth within an Envelope. H is rank 3, M is rank 2, and L is rank 1. Frames in the H Bandwidth Profile Flow are declared Green or Red. Frames in the M Bandwidth Profile Flow are declared Green, Yellow, or Red. Frames in the Page 147

158 L Bandwidth Profile Flow are declared Yellow or Red. The Bandwidth Profile Flow parameter values for this configuration are shown in Table 43 and CF 0 = 0. Bandwidth Profile Flow 3 (H) Bandwidth Profile Flow 2 (M) Bandwidth Profile Flow 1 (L) CIR 3 = CIR env CIR 2 = 0 CIR 1 = 0 3 CIR max CIR env 2 CIR max CIR env 1 CIR max = 0 CBS 3 EVC Maximum Service CBS 2 EVC Maximum Service Frame Size Service Attribute value Frame Size Service Attribute value CBS 1 = 0 EIR 3 = 0 EIR 2 = 0 EIR 1 = 0 3 EIR max = 0 2 EIR max CIR env 1 EIR max CIR env EBS 3 = 0 EBS 2 EVC Maximum Service EBS 1 EVC Maximum Service Frame Size Service Attribute value Frame Size Service Attribute value CF 3 = 0 CF 2 = 1 CF 1 = 0 ER 3 = En -1, 3 ER 2 = En -1, 2 ER 1 = En -1, 1 F 3 = 0 F 2 = 0 F 1 = 0 Table 43 Parameter Values for Sharing Bandwidth among Class of Service Names Figure 53 shows the token paths for this configuration. C n C 3 CBS 3 0 C C C 22 E 22 CBS 2 1 EBS E EBS 1 Figure 53 Bandwidth Profile Algorithm for Bandwidth Sharing among Class of Service Names X Page 148

159 D.3 Examples of the Use of the Token Request Offset Parameter This appendix presents two examples of the use of the Token Request Offset parameter. D.3.1 Adjusting for C-Tag Removal Figure 54 shows an example of using the Token Offset Parameter, F 1, to adjust for the case where each ingress C-Tagged Service Frame results in an egress Untagged Service Frame. Because of the value of the EVC EP Map Service Attribute at UNI 1, ingress Service Frames mapped to the EVC EP need to be VLAN Tagged Service Frames with the C-Tag VLAN = 24. Because of the value of the EVC EP Map Service Attribute at UNI 2 and [R107], the corresponding egress Service Frames at UNI 2 are Untagged Service Frames. Traffic Direction Ingress Bandwidth Profile 1 Ingress Tagged Service Frames UNI 1 Service Provider CEN [24 ] [17*] UNI 2 Egress Untagged Service Frames Not the Default CE-VLAN ID Value *Default CE-VLAN ID Value [x] EVC End Point Map UNI EVC EVC End Point Ingress Bandwidth Profile 1 (Single Bandwidth Profile Flow per Envelope) Bandwidth Profile Flow Parameter Parameter Value IR 1, CIR1 max 50 Mbps CBS 1 40,000 Bytes EIR 1, EIR1 max 0 Mbps EBS 1 0 Bytes CF 0, CF 1 0 CM 1 F 1 color-blind 4 Bytes Figure 54 Use of the Token Request Offset Parameter for Tagged to Untagged Service Frames Now suppose that 1000 byte Service Frames ingress at UNI 1 whenever there are sufficient Green tokens available to declare the frame as Green. If F 1 = 0, this results in 50 Mbps of ingress Service Frames that are declared Green. 57 But the corresponding egress Service Frames are only 996 bytes which means that there is only 49.8 Mbps of egress Service Frames. If the ingress Service Frames are 100 bytes, then there are only 48 Mbps of egress Service Frames. There is always bandwidth loss and the degree of loss depends on the size of the ingress Service Frames at UNI For simplicity of discussion, the transient effects of initially draining the Green token bucket are ignored. Page 149

160 By setting F 1 = 4, the C-Tag on the ingress Service Frames at UNI 1 does not consume tokens. Consequently, the ingress Service Frame pattern described in the previous paragraph results in 50 Mbps of egress Service Frames at UNI 2 no matter what the length of the ingress Service Frames at UNI 1. D.3.2 Adjusting for Inter-frame Gap, Preamble, and Frame Delimiter This example assumes that the value of Subscriber UNI Instantiation Service Attribute = Physical for the UNIs. Figure 55 shows an example of using the Token Offset Parameter, F 1, to adjust for Inter-frame Gap, Preamble and Frame Delimiter. In this case there is a C-Tag on both the ingress Service Frames at UNI 1 and the egress Service Frames at UNI 2. In addition, the line rate for UNI 1 is 1 Gbps and the line rate of UNI 2 is 100 Mbps. Now suppose that the Subscriber is shaping traffic such that a Service Frame ingresses at UNI 1 whenever there are sufficient Green tokens available to declare the frame as Green. If F 1 = 0, this results in 100 Mbps of ingress Service Frames that are declared Green. 58 At UNI 2, the egress Service Frames are separated by 20 bytes consisting of the Inter-frame Gap, Preamble, and Frame Delimiter. Thus at UNI 2, egress Service Frames cannot be generated fast enough to keep up with ingress Service Frames at UNI 1. The smaller the length of the Service Frames the greater the imbalance because more blocks of 20 bytes are inserted at the egress UNI 2. Consequently, Service Frames will eventually be discarded by the CEN. Which Service Frames are discarded will depend on the sequence of ingress Service Frame lengths. (See Appendix C for details regarding these 20 bytes.) By setting F 1 = 20, each ingress Service Frame at UNI 1 consumes an extra 20 Green tokens which results in less than 100 Mbps of Green ingress Service Frames in such a way that egress Service Frames can be generated at UNI 2 that exactly keep up with the ingress Service Frames at UNI 1 and no Service Frames will be discarded by the CEN. Note that this is true for all mixes of Service Frame lengths. 58 For simplicity of discussion, the transient effects of initially draining the Green token bucket are ignored. Page 150

161 Traffic Direction [x] Ingress Bandwidth Profile 1 Ingress Tagged Service Frames EVC End Point Map UNI 1 1 Gbps Line Rate Service Provider CEN [24 ] [24 ] UNI UNI 2 Not the Default CE-VLAN ID Value EVC Egress Tagged Service Frames 100 Mbps Line Rate EVC End Point Ingress Bandwidth Profile 1 (Single Bandwidth Profile Flow per Envelope) Bandwidth Profile Flow Parameter Parameter Value CIR 1, CIR1 max 100 Mbps CBS 1 40,000 Bytes EIR 1, EIR1 max 0 Mbps EBS 1 0 Bytes CF 0, CF 1 0 CM 1 F 1 color-blind -20 Bytes Figure 55 Use of the Token Request Offset Parameter to Adjust for Ethernet Frame Overhead D.4 Bandwidth Profile Implementation This appendix addresses implementation considerations for a Bandwidth Profile. D.4.1 Eliminating Bias Toward Short Service Frames In some circumstances the Bandwidth Profile algorithm specified in Section 13.2 can have a bias in favor of short Service Frames and against long Service Frames. The circumstance where this behavior arises is when the arriving traffic exceeds the specified rate (CIR and/or EIR) over a time interval significantly greater than can be accommodated by the specified burst tolerance (CBS and/or EBS). This behavior could be problematic for some applications. For instance, in an environment that typically handles a large number of simultaneous TCP connections, discarding long frames with a higher probability than short frames could conceivably create a situation where new connections are easily established but existing connections are unable to efficiently complete data transfers. In such environments it may be desirable to implement a modification of the Bandwidth Profile algorithm that eliminates the bias toward short Service Frames by making the color declaration of any Service Frame independent of the size of that frame. The bias toward short Service Frames occurs when the token bucket is near empty. For simplicity, consider an example with a single token bucket (e.g. CBS > the value of the EVC Maximum Service Frame Size Service Attribute and EBS = 0). When the number of tokens in the bucket is less than the maximum frame size, a short frame will be declared Green while a long frame will Page 151

162 be declared Red. The arrival of a short frame will deplete the number of tokens in the bucket still further, which decreases the probability that a subsequent long frame would be declared Green. The arrival of several consecutive long frames may allow the bucket to refill sufficiently to declare an occasional long frame Green, but this depletes the bucket again which reinstates the condition for the short frame bias for subsequent frames. The behavior is self-reinforcing as long as the rate of arriving traffic exceeds the rate at which tokens are added to the bucket. A Bandwidth Profile algorithm implementation can eliminate the bias toward short frames by making the decision to declare an arriving frame Green, Yellow, or Red independent of the length of the frame. This requires two things. First, declare an arriving Service Frame Green if there are any tokens in the bucket, instead of comparing the length of the Service Frame to the number of tokens in the bucket. If the frame length is greater than the number of tokens in the bucket, then declaring the frame Green may result in the token count going negative by up to a maximum frame size (effectively borrowing future tokens). This has a side effect of increasing the effective burst size by up to a maximum frame size. Second, measure the time interval between frames from the first bit of the previous frame to the first bit of the current frame, as opposed to measuring from the last bit of the previous frame to the last bit of the current frame. Measuring last bit to last bit actually introduces a bias toward long frames because of the tokens added to the bucket between the first bit and the last bit of the current frame. Figure 56, Figure 57, and Figure 58 show simulation results of these variations on the Bandwidth Profile algorithm. The simulation is of an Ingress Bandwidth Profile on a 100Mbps UNI with CIR = 10Mbps, CBS = 1200B, and EIR = EBS = 0. The value of the Subscriber UNI Instantiation Service Attribute = Physical. The ingress traffic is a mix of 60% short (300 byte) and 40% long (1200 byte) Service Frames arriving in a randomized sequence with minimum inter-frame gap. Figure 56 is the unmodified Bandwidth Profile algorithm of Section After the initial transient when the token bucket gets depleted, short frames are declared Green in a dramatically higher percentage than long frames Figure 56 Service Frame Profiling Results for the Algorithm of Section 13.2 Figure 57 shows the Bandwidth Profile algorithm modified to test for more than zero tokens in the bucket instead of more than the current frame length worth of tokens, but measures the time interval from the last bit of the previous frame to the last bit of the current frame. After the initial transient, the percentage of long frames declared Green is significantly higher than the percentage of long frames in the ingress traffic pattern. Page 152

163 Figure 57 Service Frame Profiling Results for Modified Algorithm (Time Measured Last Bit to Last Bit) Figure 58 shows the Bandwidth Profile algorithm modified to test for more than zero tokens in the bucket instead of more than the current frame length worth of tokens, and measures the time interval from the first bit of the previous frame to the first bit of the current frame. After the initial transient, the percentage of short and long frames declared Green is roughly equivalent to the percentage of short and long frames in the ingress traffic pattern Figure 58 Service Frame Profiling Results for Modified Algorithm (Time Measured First Bit to First Bit) Table 44 shows the numbers of each type of Service Frame declared Green by the three algorithms for the last 250 Service Frames in the simulation which corresponds to the behavior after the initial draining of the tokens. The first row is the offered traffic since all Service Frames not subject to an Ingress Bandwidth Profile are declared Green. The last two columns show the results as a percentage of the total number of Service Frames declared Green. Green Short Service Frames Green Long Service Frames Percent Green Short Service Frames Percent Green Long Service Frames No Bandwidth Profile % 37% Algorithm of Section % 0% Modified Algorithm (Time Measured Last Bit to Last % 76% Bit) Modified Algorithm (Time Measured First Bit to First Bit) % 30% Table 44 Service Frame Profiling Results for the Last 250 Service Frames Page 153