Mef 10.3

Ethernet Services Attributes Phase 3
1975
10. Bandwidth Profile at the UNI

A Bandwidth Profile is a method characterizing Service Frames for the purpose of rate enforcement or policing. There are two types of Bandwidth Profile. An Ingress Bandwidth Profile is used to regulate the amount of ingress traffic at a particular UNI, while an Egress Bandwidth Profile is used to regulate the amount of egress traffic at a particular UNI. The Ingress Bandwidth Profile is described in Section 10.3. The Egress Bandwidth Profile is described in Section 10.4. A Bandwidth Profile is a characterization of the lengths and arrival times for Service Frames at a reference point. For the Ingress Bandwidth Profile, this reference point is the ingress UNI. For the Egress Bandwidth Profile, this reference point is the egress UNI. Typically a Bandwidth Profile defines Service Frame traffic that is less than the full bandwidth of the UNI. Bandwidth Profiles are associated with the UNI. This allows different Bandwidth Profiles at each UNI in an EVC. For example, on a Multipoint-to-Multipoint EVC, a different Bandwidth Profile could apply at each UNI in the EVC. The Bandwidth Profile defines 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. In the case of an Ingress Bandwidth Profile, rate enforcement is accomplished via the disposition of Service Frames. All Bandwidth Profiles in this Technical Specification are based on the parameters and algorithm described in this Section. Editor Note 40: The conference calls have been discussing how Bandwidth Profile relates to the concepts of Bandwidth Profile Flow and Envelope. This text associates Bandwidth Profile with an Envelope. Thus a Bandwidth Profile is a characterization of the Service Frames within an Envelope. A Bandwidth Profile is specified using the concepts of Bandwidth Profile Flow and Envelope. A Bandwidth Profile Flow is defined as a set of Service Frames arriving at a UNI that meet a specific criterion. Editor Note 41: On the 8/14/2012 call there was discussion about changing the following requirement to allow more flexibility, e.g., to base a Bandwidth Profile Flow on the Destination Address type. No conclusions have been reached as of this writing. [R151] A Bandwidth Profile Flow MUST be specified using one of the following six criteria:
1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008
MEF 10.3 Working Draft 0.1.7
The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is authorized to modify any of the information contained herein.
Page 76

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044
1. 2.
All ingress Service Frames at the UNI that are not discarded per requirements [R16], [R70], [R81], [R82], [R94], [R109], [R147], [D1], or [O6], All ingress Service Frames at the UNI that are mapped to a given EVC and that are not discarded per requirements [R16], [R70], [R81], [R82], [R94], [R109], [R147], [D1], or [O6], All ingress Service Frames at the UNI that have a given Class of Service Identifier value and that are not discarded per requirements [R16], [R70], [R81], [R82], [R94], [R109], [R147], [D1], or [O6], All egress Service Frames at the UNI, All egress Service Frames at the UNI that are mapped to a given EVC, or All egress Service Frames at the UNI that have a given Egress Equivalence Class Identifier value,
3.
4. 5. 6.
Note that in some cases the criteria in the above requirements can be equivalent, e.g., criterion 1 and criterion 2 are equivalent at a UNI with All to One Bundling Enabled and Reserved CEVLAN IDs Disabled since there is only one EVC at the UNI and all Service Frames map to it (see Section 7.14). Note that criteria 1, 2, and 3 of [R151] mean that ingress Service Frames discarded per requirements [R16], [R70], [R81], [R82], [R94], [R109], [R147], [D1], or [O6] cannot be in a Bandwidth Profile Flow and thus they will not consume tokens in the Bandwidth Profile Algorithm described in Section 10.1. An Envelope is a set of n Bandwidth Profile Flows in which each Bandwidth Profile Flow is assigned a unique rank between 1 (lowest) and n (highest). n can be any positive integer. [R152] All Bandwidth Profile Flows in an Envelope MUST satisfy the same criterion in [R151].
One implication of [R152] is that the Bandwidth Profile Flows in an Envelope are either all Ingress Bandwidth Profile Flows or all Egress Bandwidth Profile Flows. When the Envelope contains Bandwidth Profile Flows meeting either criterion 1 or criterion 4 of [R151], there is just one Bandwidth Profile Flow in the Envelope. Editor Note 42: There has been discussion about restricting all Bandwidth Profile Flows based on mapping to an EVC (criterion 2 or criterion 5 of [R151]) to be in a single Envelope. This would mean replacing the following paragraph with a requirement mandating the restriction. Multiple Envelopes containing Bandwidth Profile Flows meeting criterion 2 of [R151] can coexist at a UNI, each based on disjoint set of EVCs. Similarly multiple Envelopes containing Bandwidth Profile Flows meeting criterion 5 of [R151] can co-exist at a UNI, each based on disjoint set of EVCs.
Page 77

2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058
Multiple Envelopes containing Bandwidth Profile Flows meeting criterion 3 of [R151] can coexist at a UNI, each based on disjoint set of Class of Service Identifier values. Similarly multiple Envelopes containing Bandwidth Profile Flows meeting criterion 6 of [R151] can co-exist at a UNI, each based on disjoint set of Egress Equivalence Class Identifier values. [R153] [R154] Each Bandwidth Profile Flow at a UNI MUST belong to exactly one Envelope. A Service Frame MUST be mapped to at most one Bandwidth Profile Flow.
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, [R153] and [R154] mean that this Service Frame will be subject to exactly one Envelope and thus the Bandwidth Profile algorithm of [R172] is applied to this Service Frame exactly once. As a consequence, each Service Frame mapped to a Bandwidth Profile Flow will have exactly one color declaration. 10.1 Bandwidth Profile Parameters and Algorithm
2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077
Editor Note 43: The 14 February 2012 conference call agreed that we need additional parameters to use to describe the mapping of Bandwidth Profile Flows to envelope. To this end, parameters Bandwidth Profile Flow Identifier, Envelope Identifier, and Bandwidth Profile Flow to Envelope Mapping are introduced. 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 Envelope. The significance of the ranking of the Bandwidth Profile Flows is that the algorithm may reallocate unused bandwidth from a given Bandwidth Profile Flow to lower rank Bandwidth Profile Flows, but not to higher rank Bandwidth Profile Flows. Editor Note 44: During the 8/14/2012 conference call it was agreed to add the parameter CF0. Each Envelope at a UNI has a two parameters, the Envelope ID and the Envelope Coupling Flag, CF0. [R155] [R156] [R157] [R158] [R159] The Envelope ID MUST contain no more than 45 characters.5 The Envelope ID MUST be unique among all Envelope IDs at a UNI. The Envelope ID MUST be an RFC 2579 [14] DisplayString but not contain the characters 0x00 through 0x1f. CF0 MUST have only one of two possible values, 0 or 1. When one Bandwidth Profile Flow is mapped to an Envelope, CF0 MUST equal 0.
Page 78

2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107
Note that the concatenation of the UNI ID and the Envelope ID is unique among all Envelopes for the CEN. The parameters comprising the Bandwidth Profile parameters comprised of parameters per rank i for i = 1,2,..., n : Committed Information Rate per Bandwidth Profile Flow (CIRi) expressed as bits per second.
[R160]
CIRi MUST be 0.
Maximum Committed Information Rate per Bandwidth Profile Flow (CIRimax) expressed as bits per second.
[R161]
CIRimax MUST be 0
Committed Burst Size per Bandwidth Profile Flow (CBSi) expressed as bytes.
[R162]
When CIRi > 0, CBSi MUST be greater than or equal to the largest EVC Maximum MAC Client Data Field Size value of the EVCs that Service Frames in the Bandwidth Profile Flow are mapped to plus 18. See Section 6.9.
Excess Information Rate per Bandwidth Profile Flow (EIRi) expressed as bits per second.
[R163]
EIRi MUST be 0.
Maximum Excess Information Rate per Bandwidth Profile Flow (EIRimax) expressed as bits per second.
[R164]
EIRimax MUST be 0.
Excess Burst Size per Bandwidth Profile Flow (EBSi) expressed as bytes.
[R165]
When EIRi > 0, EBSi MUST be greater than or equal to the largest EVC Maximum MAC Client Data Field Size value of the EVCs that Service Frames in the Bandwidth Profile Flow are mapped to plus 18. See Section 6.8.5.
Coupling Flag per Bandwidth Profile Flow (CFi).
[R166] [R167]
CFi MUST have only one of two possible values, 0 or 1. If CF0 = 1 for an Envelope, then CFi MUST equal 0 for all Bandwidth Profile Flows mapped to the Envelope.
Color Mode per Bandwidth Profile Flow (CMi).

Page 79

2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140
[R168]
CMi MUST have only one of two possible values, color-blind and coloraware.
Envelope and Rank (ERi) a pair <Envelope ID, positive integer>. The Envelope ID indicates the Envelope that the Bandwidth Profile Flow belongs to and the positive integer specifies the rank of the Bandwidth Profile Flow within the Envelope.
[R169]
The value of the positive integer value in ERi MUST be in the range [1,, n] where n is the number of Bandwidth Profile Flows with the same Envelope ID value. The value of the positive integer value in ERi MUST not equal the positive integer value of any of the other Bandwidth Profile Flows with the same Envelope ID value.
[R170]
Each Service Frame is classified to determine which, if any, Envelope is applicable to the Service Frame.25 Operation of the Bandwidth Profile algorithm is governed by the parameters, <CIRi, CIRimax, CBSi, EIRi, EIRimax, EBSi, CFi, CMi> for i = 1,2,..., n . The algorithm declares each Service Frame to 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.26 The Bandwidth Profile algorithm is said to be in color aware mode for Bandwidth Profile Flow i when each Service Frame in Bandwidth Profile Flow i that already has a level of compliance (i.e., a color) associated with it via the Color Identifier (see Section 8.3) 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 Bandwidth Profile Flow i is ignored by the Bandwidth Profile Algorithm.
[R171] [O9]
A UNI MUST be able to support Color blind mode for Bandwidth Profiles. A UNI MAY support Color aware mode for Bandwidth Profiles.
The color mode of operation for Bandwidth Profile Flow i is determined using the parameter CMi. A token bucket model is used to describe the Bandwidth Profile behavior. Each Bandwidth Profile Flow i has a committed token bucket that can contain up to CBSi tokens, and an excess token bucket that can contain up to EBSi tokens. Tokens for each bucket are sourced at a rate of CIRi and EIRi respectively. Tokens that overflow each bucket may be made available to other buckets depending on the setting of the Coupling Flags (CFi) and mapping Bandwidth Profile Flows to
Recall that a Service Frame is defined as any Ethernet Frame transmitted across the UNI and thus a Layer 2 Control Protocol Ethernet frame is a Service Frame and thus can be subject to a Bandwidth Profile. 26 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. MEF 10.3 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall contain the Page 80 following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is Working authorized to modify any of the information contained herein. Draft 0.1.7
25

2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173
an Envelope. Tokens flowing into a bucket are limited to CIRimax and EIRimax 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 Indication 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 a number of tokens equal to the length of that Service Frame is removed from the committed bucket for that Bandwidth Profile Flow. When a Service Frame for Bandwidth Profile Flow i is declared Yellow a number of tokens equal to the length of that Service Frame is removed from the excess bucket for that Bandwidth Profile Flow. To specify the Bandwidth Profile behavior, we define the following functions:
i i BC (t ) and BE (t ) represent the number of tokens in the committed and excess token buckets, respectively, for Bandwidth Profile Flow i at time t, for i = 1,2,..., n .
TCi (t1 ,t 2 ) and TEi (t1 , t 2 ) represent the maximum number of tokens that might be added to the committed and excess token buckets, respectively, for Bandwidth Profile Flow i over the time interval t1 to t 2 , for i = 1,2,..., n .
i i AC (t1 ,t 2 ) and AE (t1 ,t 2 ) represent the number of tokens actually added to the committed and excess token buckets, respectively, for Bandwidth Profile Flow i over the time interval t1 to t 2 for i = 1,2,..., n . i i OC (t1 ,t 2 ) and OE (t1 , t 2 ) represent the number of tokens that overflow the committed and excess
token buckets, respectively, for Bandwidth Profile Flow i over the time interval t1 to t 2 for i = 1,2,..., n .
i i S C (t1 , t 2 ) and S E (t1 , t 2 ) represent the number of tokens available to be shared to the committed and excess token buckets of Bandwidth Profile Flow i 1 , respectively, from Bandwidth Profile Flow i over the time interval t1 to t 2 for i = 1,2,..., n, n + 1 .
The maximum number of tokens that might be added to the committed token bucket, TCi (t1 ,t 2 ) , includes tokens sourced at the Committed Information Rate ( CIRi ) over the time interval and any tokens shared from the next higher rank Bandwidth Profile Flow. The maximum number of tokens that might be added to the excess token bucket, TEi (t1 , t 2 ) , includes tokens sourced at the Excess Information Rate ( EIR i ) over the time interval, any tokens shared from the higher rank Bandwidth Profile Flow, and any overflow tokens from the committed token bucket that are allowed by the Coupling Flag ( CF i ). Note that Bandwidth Profile Flow n has no tokens shared from a higher rank since there are no Bandwidth Profile Flows with a rank higher than n. Theren n fore S C +1 (t1 , t 2 ) = S E +1 (t1 , t 2 ) = 0 .
Page 81

2174
CIR i i T (t1 , t 2 ) = (t 2 t1 ) + S C+1 (t1 , t 2 ) 8

i C
2175
Editor Note 45: During the 8/14/2012 conference call it was agreed to add the parameter CF0. TEi (t1 , t 2 ) = TEn (t1 , t 2 ) = EIR i i i (t 2 t1 ) + S E+1 (t1 , t 2 ) + CF i OC (t1 , t 2 ) for i = 1,2,..., n 1 8 EIR n n 1 (t2 t1 ) + CF 0 OC (t1 , t 2 ) + CF n OC (t1 , t2 ) 8
2176
2177
2178 2179 2180 2181
Note that [R167] mandates that CFn = 0 if CF0 =1 in the equation for TEn (t1 ,t2 ) . The number of tokens actually added to the token bucket is some or all of the tokens available to be added, limited by the maximum number of tokens allowed in the token bucket ( CBS i and
i i EBS i ) and by the maximum rate at which tokens are allowed to be added ( CIRmax and EIRmax ).
2182
i CIRmax i i AC (t1 , t 2 ) = min TCi (t1 , t 2 ), CBS i BC (t1 ), (t 2 t1 ) 8 i EIRmax i i AE (t1 , t 2 ) = min TEi (t1 , t 2 ), EBS i BE (t1 ), (t 2 t1 ) 8
2183 2184 2185
The number of tokens that overflow each token bucket is the number of available tokens that are not actually added to the token bucket.
i i OC (t1 , t 2 ) = TCi (t1 , t 2 ) AC (t1 , t 2 ) i i OE (t1 , t 2 ) = TEi (t1 , t 2 ) AE (t1 , t 2 )
2186 2187 2188 2189 2190 2191 2192
The number of tokens available to be shared from Bandwidth Profile Flow i to the next lower rank Bandwidth Profile Flow, i 1 , is the number of tokens that overflow the committed and excess token buckets and, in the case of the committed token bucket, are not made available to the excess token bucket by the Coupling Flag, CF i .
i i S C (t1 , t 2 ) = (1 CF i ) OC (t1 , t 2 ) . i i S E (t1 , t 2 ) = OE (t1 , t2 )
2193 2194 2195
The Bandwidth Profile algorithm for an Envelope is shown in Figure 28. A visual representation of the algorithm is presented in Appendix Error! Reference source not found..
Page 82

2196 2197 2198 2199 2200 2201
[R172]
For an Envelope and for a sequence of Service Frames, {t j , l j , i j }, j 0, t j +1 t j ,i j {1,2,..., n} with arrival times at the reference point at times t j , lengths l j , and Bandwidth Profile Flows i j that are mapped to the Envelope, the level of compliance assigned to each Service Frame MUST i be defined according to the algorithm in Figure 28 where BC (t 0 ) = CBS i and
i BE (t 0 ) = EBS i .
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 :
i i i BC (t j ) = BC (t j 1 ) + AC (t j 1 , t j ) i i i BE (t j ) = BE (t j 1 ) + AE (t j 1 , t j )
[(CM == color - blind ) OR

(Service Frame Color Indication == Green ) OR (no Service Frame Color Indication )]
AND l j BCj (t j )
i
Yes
Declare Service Frame Green BCj (t j ) = BCj (t j ) l j

i i
)
Yes
Declare Service Frame Yellow BEj (t j ) = BEj (t j ) l j
i i
No
l j BEj (t j )
i
No Declare Service Frame Red

2202 2203
Figure 28 The Bandwidth Profile Algorithm for an Envelope
2204 2205 2206 2207 2208 2209 2210
Editor Note 46: The following replacement text was agreed to during the 8/28/2012 call.
Note that this document does not mandate how the behavior specified in Figure 28 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 theoretically impossible to achieve the exact behavior described in Figure 28. A practical implementation needs to yield behavior "close" to the ideal behavior. Defining "close" is beyond the scope of this document.
Page 83

2211
10.2
Bandwidth Profile without Sharing
2212 2213 2214
The algorithm of Figure 28 reduces to the Bandwidth Profile algorithm of Figure 13 of MEF 10.2 [16] when there is only one Bandwidth Profile Flow mapped to an Envelope and both 1 1 CIRmax and EIRmax are sufficiently large. The following derivation demonstrates this fact.
1 1 When n = 1 , CIRmax CIR1 , and EIRmax EIR1 + (CF 1 CIR1 ) ,
2215
2216
1 TC (t1 , t2 ) =
CIR1 CIR1 n (t2 t1 ) + S C +1 (t1 , t 2 ) = (t 2 t1 ) and 8 8 EIR1 EIR1 1 n 1 (t2 t1 ) + CF 1 OC (t1 , t2 ) + S E +1 (t1 , t 2 ) = (t2 t1 ) + CF 1 OC (t1 , t 2 ) . 8 8
2217
1 TE (t1 , t2 ) =
2218 2219 2220
Recall that [R159] mandates CF0 = 0 when there is only one Bandwidth Profile Flow mapped to the Envelope.
1 Since CIRmax CIR1 , it follows that 1 CIR1 CIRmax 1 1 AC (t1 , t2 ) = min (t2 t1 ), CBS 1 BC (t1 ), (t2 t1 ) 8 8 CIR1 1 = min (t 2 t1 ), CBS 1 BC (t1 ) 8
2221
2222
and
1 1 1 OC (t1 , t 2 ) = TC (t1 , t 2 ) AC (t1 , t 2 ) =
CIR1 CIR1 1 (t 2 t1 ) min (t 2 t1 ), CBS 1 BC (t1 ) 8 8
2223
1 = BC (t1 ) +
1 CIR1 CIR1 (t 2 t1 ) CBS 1 min BC (t1 ) + (t 2 t1 ) CBS 1 ,0 8 8
1 CIR1 = max BC (t1 ) + (t 2 t1 ) CBS 1 ,0. 8

2224
1 Since EIRmax EIR1 + (CF 1 CIR1 ) ,
2225
1 EIR1 EIRmax 1 1 1 AE (t1 , t 2 ) = min (t 2 t1 ) + CF 1 OC (t1 , t 2 ), EBS 1 BE (t1 ), (t 2 t1 ) 8 8 EIR1 1 1 = min (t 2 t1 ) + CF 1 OC (t1 , t 2 ), EBS 1 BE (t1 ). 8
Page 84

2226
Then the computation of the number of tokens in each bucket is 1 CIR1 1 1 1 BC (t 2 ) = BC (t1 ) + AC (t1 , t 2 ) = min BC (t1 ) + (t 2 t1 ), CBS 1 and 8 1 EIR1 1 1 1 1 BE (t 2 ) = BE (t1 ) + AE (t1 , t 2 ) = min BE (t1 ) + (t 2 t1 ) + CF 1 OC (t1 , t 2 ), EBS 1 . 8 Inspection of these equations reveals that the token counts depend on just the parameters for Bandwidth Profile Flow 1. Thus the level of compliance for each Service Frame in Bandwidth Profile Flow 1 is determined by the algorithm in Figure 29.
Service Frame of length l j arrives at time t j for Flow 1
2227
2228
2229 2230 2231 2232
1 CIR1 i BC (t j ) = min BC (t1 ) + (t2 t1 ), CBS 1 8 1 1 CIR 1 OC (t1 , t 2 ) = max BC (t1 ) + (t2 t1 ) CBS 1 ,0. 8 1 EIR1 1 1 BE (t j ) = min BE (t1 ) + (t 2 t1 ) + CF 1 OC (t1 , t 2 ), EBS 1 8
[(CM == color - blind ) OR

(Service Frame Color Indication == Green ) OR (no Service Frame Color Indication )]
1 AND l j BC (t j )
Yes
Declare Service Frame Green

1 1 BC (t j ) = BC (t j ) l j
)
Yes Declare Service Frame Yellow
B1 (t j ) = B1 (t j ) l j E E
No
l j B1 (t j ) E
No Declare Service Frame Red

2233 2234
Figure 29 Bandwidth Profile Algorithm for one Bandwidth Profile Flow in an Envelope
2235 2236 2237
Figure 29 is equivalent to Figure 13 of MEF 10.2 [16] and thus the algorithm of Figure 28 is backward compatible with the Bandwidth Profile algorithm of [16] when a single Bandwidth Profile Flow is in an Envelope.
Page 85

2238
10.3
Ingress Bandwidth Profiles Service Attributes
2239 2240 2241 2242 2243 2244
The Ingress Bandwidth Profile is used to regulate the amount of ingress traffic at a particular UNI. An Ingress Bandwidth Profile is defined for ingress Service Frames at the particular UNI. In other words, the sequence {t j , l j , i j }, j 0, to which the algorithm of Section 10.1 is applied is based on ingress Service Frames at a UNI. There are three Ingress Bandwidth Profile models as described in Sections 7.15, 8.4, and 8.6.
10.3.1 Service Frame Disposition
2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260
The disposition of a given ingress Service Frame with respect to delivery to an egress UNI is dependent on the Service Frames level of compliance to the Ingress Bandwidth Profile that is applied to it. This is called the Ingress Bandwidth Profile compliance level and it has three possible values: Green, Yellow, or Red. An ingress Service Frame that is declared Red by an Ingress Bandwidth Profile MUST be discarded. Note that if an ingress Service Frame is declared Green by an ingress Bandwidth Profile and it meets other conditions per the definition of Qualified Service Frame [R28] in Section 6.8, then the SLS applies to this Service Frame. Note that, per the definition of Qualified Service Frame in [R28] in Section 6.8, an ingress Service Frame that is declared Yellow by an ingress Bandwidth Profile is not subject to the performance objectives of the SLS. The better the level of Ingress Bandwidth Profile compliance the fewer Service Frames will be discarded by the ingress Bandwidth Profile. In order to improve the level of Ingress Bandwidth Profile compliance, a Subscriber may need to shape traffic in the CE (see Section A.3).
10.4 Egress Bandwidth Profiles Service Attributes
2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271
An Egress Bandwidth Profile is used to regulate the amount of egress traffic at a particular UNI. An Egress Bandwidth Profile is defined for a particular UNI and applies to all or a subset of all egress Service Frames at the UNI in question. The reference point for an Egress Bandwidth Profile is the egress UNI. An Egress Bandwidth Profile describes arrival times and lengths of Service Frames that will be observed at the egress UNI when an Egress Bandwidth Profile is in operation in the Service Provider network. This description is given in terms of what would happen if an observer at the egress UNI applied the algorithm of Section 10.1 to egress Service Frames. This observer would see traffic after it had been subject to rate limiting and/or shaping in the Service Provider network and thus would have certain characteristics. These characteristics are described in terms of the behavior of the algorithm of Section 10.1 when run by the observer.
Page 86

2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284
[R173]
When a sequence of egress Service Frames is subject to an Egress Bandwidth Profile with parameters <CIRi, CIRimax, CBSi, EIRi, EIRimax, EBSi, CFi, CMi> for i = 1,2,..., n application of the algorithm of Section 10.1 to these egress Service Frames, MUST be to declare each Service Frame either Green or Yellow.
The implication is that the regulation of the Service Frames in the Service Provider network is such that all Service Frames that would determined to be Red by the observer are discarded before reaching the egress UNI. It is important to reiterate that this description of Egress Bandwidth Profile does not mandate or constrain in any way the implementation in the Service Provider network. There are three Egress Bandwidth Profile models as described in Sections 7.16, 8.7, and 8.8.
10.5 Simultaneous Application of the Ingress Bandwidth Profile Application Models [O10]
2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301
Multiple models of Ingress Bandwidth Profile application MAY exist simultaneously at a UNI.
Editor Note 47: Per the 8/14/2012 conference call, the addition of [R154] means that the requirement "A UNI MUST be configured such that only a single Ingress Bandwidth Profile applies to any given ingress Service Frame." is redundant and is therefore deleted. In view of [R154]: If there is a per UNI Ingress Bandwidth Profile, then there cannot be any other Ingress Bandwidth Profiles at that UNI. If there is a per EVC Ingress Bandwidth Profile on an EVC, then there cannot be any per Class of Service Ingress Bandwidth Profiles on that EVC.
For example, in the configuration of Figure 25, there cannot be an Ingress Bandwidth Profile for EVC1. Note also for the configuration in Figure 25, that it is possible to configure a per-EVC Ingress Bandwidth Profile for EVC2 but there happens to not be an Ingress Bandwidth Profile for EVC2 in this example.
10.6 Simultaneous Application of the Egress Bandwidth Profile Application Models [O11]
2302 2303 2304 2305
Multiple models of Egress Bandwidth Profile application MAY exist simultaneously for an egress UNI.
Editor Note 48: Per the 8/14/2012 conference call, the addition of [R154] means that the requirement "A UNI MUST be configured such that only a single Egress BandMEF 10.3 Working Draft 0.1.7
Page 87

2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331
width Profile applies to any given ingress Service Frame." is redundant and is therefore deleted. In view of [R154]: If there is a per UNI Egress Bandwidth Profile, then there cannot be any other Egress Bandwidth Profiles at that UNI. If there is a per EVC Egress Bandwidth Profile on an EVC, then there cannot be any per Class of Service Identifier Egress Bandwidth Profiles on that EVC.
Appendix A
A.1
Bandwidth Profiles (Informative)
Visual Representation of the Bandwidth Profile
Error! Reference source not found. shows a conceptual diagram of the Bandwidth Profile Algorithm with three Bandwidth Profile Flows.
The green and yellow trapezoids represent the Committed and Excess token buckets for each Bandwidth Profile Flow. The solid arrows labeled CIRi or EIRi represent a token source flowing into each bucket at the rate specified by the Bandwidth Profile. The dashed arrows show where tokens that overflow the bucket go when the number of tokens in the bucket reaches the capacity (CBSi or EBSi) specified by the Bandwidth Profile. The circles represent decision points in the path of the overflow tokens that are controlled by the Coupling Flag (CFi). The Xs represent points at which tokens are discarded (i.e., not added to the token count for any of the buckets). CIRimax and EIRimax are not shown on the figure.
The Coupling Flag for each Bandwidth Profile Flow controls the path of overflow tokens from the Committed token bucket to the Excess token bucket.
Page 88

2332
CIR3 EIR3 CF3 0 1 EBS3
CBS3
CIR2 EIR2 CF2 0 1 EBS2
CBS2
CIR1 EIR1 CF1 0 0 CF0

2333 2334
1 EBS1 1
CBS1
Figure 30 Behavior of the Bandwidth Profile Algorithm A.2 Bandwidth Profile Use Cases
2335 2336 2337
Editor Note 49: The following three use cases came out of the January 3 conference call.
A.2.1 Sharing Excess Bandwidth
2338 2339 2340 2341 2342 2343 2344 2345
In this use case, three Bandwidth Profile Flows are included in an Envelope with each Bandwidth Profile Flow having a dedicated CIRi. 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 CIRi 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 . Error! Reference source not found. shows i the token paths for this configuration. Note that EIRmax , i = 1,2,3 are not shown in Error! ReferMEF 10.3 Working Draft 0.1.7
Page 89

2346 2347
ence source not found. for simplicity but their values can be set to limit the excess bandwidth available to a given Bandwidth Profile Flow.
CIR3 EIR3 CF3 1 EBS3
CBS3
CBS2
CBS1
2348 2349 2350
Figure 31 Bandwidth Profile Algorithm for Sharing Excess Bandwidth

A.2.2 Uncoupled Bandwidth Sharing
2351 2352 2353 2354 2355
In this use case, three Bandwidth Profile Flows are included in an Envelope. The Bandwidth Profile Flows share CIRenv committed bandwidth and EIRenv excess bandwidth. Overflows of Green tokens are not converted to Yellow tokens. The configuration of this example is CF 0 = 0, CF i = 1, i = 1,2,3 , CIR 3 = CIRenv , and EIR 3 = EIRenv . Error! Reference source not found. shows the token paths for this configuration.
Page 90
CIRenv EIRenv CF3 0 EBS3
CBS3
CBS2
CF2 0 EBS2
CBS1
CF1 0 EBS1
2356 2357
Figure 32Bandwidth Profile Algorithm for Uncoupled Bandwidth Sharing
2358 2359 2360 2361 2362 2363 2364 2365 2366 2367
The amount of bandwidth of Qualified Service Frames for each Bandwidth Profile Flow can 2 range from 0 to CIRenv . CIR1 and CIR max can be used to limit committed bandwidth for Bandmax width Profile Flows 1 and 2 if so desired by the Service Provider and agreed to by the Subscrib2 er. Similarly, EIR 1 and EIR max can be used to limit excess bandwidth for Bandwidth Profile max Flows 1 and 2 if so desired by the Service Provider and agreed to by the Subscriber. A similar but different use case is to make CIR1 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.
A.2.3 Sharing Bandwidth among Class of Service Identifier Values
2368 2369 2370
In this case, CoS Labels H, M, and L share CIRenv 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 L
Page 91

2371 2372 2373
Bandwidth Profile Flow are declared Yellow or Red. The Bandwidth Profile Flow parameter values for this configuration are shown in Error! Reference source not found. and CF 0 = 0 .
Parameter Bandwidth Profile Flow 3 (H) CIRenv >0 0 0 0 Bandwidth Profile Flow 2 (M) 0 Bandwidth Profile Flow 1 (L) 0
CIR CBS EIR EBS CF

2374
>0 0 >0 1
0 0 >0 0
Table 16 Parameter Values for Sharing Bandwidth among Class of Service Identifiers Error! Reference source not found. shows the token paths for this configuration.
CIR3
2375
CBS3
CF3 0
CIR2
CBS2
CF2
1 EBS2
EBS1
2376 2377 2378
Figure 33Bandwidth Profile Algorithm for Bandwidth Sharing among Class of Service Identifiers
Page 92

2379
A.2.4
Active/Standby EVCs
2380 2381 2382 2383 2384
Error! Reference source not found. 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 active EVC fails, the Mobile Operator routers start sending data on the backup EVC.
RAN-NC UN I Active/Standby EVC Cell Site UNI
2385 2386
RAN-NC UN I
Standby/Active EVC
Figure 34 Active/Standby EVCs Use Case
2387 2388 2389 2390 2391 2392 2393 2394 2395 2396
The Service Provider constructs the Ingress Bandwidth Profile at the Cell Site UNI to limit the aggregate bandwidth allocated to the two EVCs. For this example, there are three Class of Service Identifier values supported on each EVC that map to the Class of Service Labels H, M, and L as specified in MEF 23.1. [26] To configure the Ingress Bandwidth Profile at the Cell Site UNI, six Bandwidth Profile Flows are specified, one each for each Class of Service Identifier value on an EVC. The six Bandwidth Profile Flows are mapped to three Envelopes as shown in Error! Reference source not found.. Recall that the Ingress Bandwidth Profile at the Cell Site is applied to traffic moving from right to left.
CIRH , CBS H , EIRH , EBS H ,... CIRM , CBS M , EIRM , EBS M ,... CIRL , CBS L , EIRL , EBS L ,...
3 Envelopes, one each for H, M, and L Active/Standby EVC
EVCA
UNI1 EVCA UNI
H M L
EVCS
UNI2
EVCS
M L
Standby/Active EVC
2397 2398 2399
Figure 35 Mapping of 6 Bandwidth Profile Flows to 3 Envelopes for the Active/Standby Use Case
Page 93

2400 2401 2402 2403 2404 2405 2406 2407
The parameters shown in Error! Reference source not found. for each Envelope are set to accommodate the aggregate bandwidth for the given Class of Service Identifier value. For example, the values for the parameters CIRH , CBS H , EIRH , EBS H ,... are set based on the aggregate H cell user traffic plus the aggregate mobile network control traffic including the routing protocols. Error! Reference source not found. shows how the Ingress Bandwidth Profile Bandwidth Profile Flow parameter values are set for the H Bandwidth Profile Flows. For the Envelope, CF 0 = 0 .
Bandwidth Profile Flow 1: H Service Frames Mapped to Standby EVC Bandwidth Profile Flow 2: H Service Frames Mapped to Active EVC
Parameter CIR 1 CBS 1
EIR1 EBS 1 CF 1 1 CIRmax

1 EIRmax
Value 0 CBS H 0 EBS H 0

Parameter CIR 2 CBS 2
EIR 2 EBS 2 CF 2 2 CIRmax

2 EIRmax
Value CIRH CBS H EIRH EBS H 0

2408
Table 17 Ingress Bandwidth Profile Parameter Values for the H Bandwidth Profile Flows Error! Reference source not found. shows the resulting Ingress Bandwidth Profile algorithm for the Envelope of H Bandwidth Profile Flows. As can be seen, the combined long term average bandwidth of ingress Green Service Frames on the two EVCs is CIRH.
2409 2410 2411
Page 94
CIRH EIRH
Flow 2: H Service Frames mapped to EVCA (Active/Standby)
CBSH
CF2 0 EBSH
Flow 1: H Service Frames mapped to EVCS (Standby/Active)

2412 2413 2414
CBSH
CF1 0 EBSH
Figure 36 Bandwidth Profile Algorithm for the Envelope of H Bandwidth Profile Flows
Similar parameter setting and token sharing apply to the Envelope of M Bandwidth Profile Flows and the Envelope of L Bandwidth Profile Flows.
A.2.5 Sequential Use Case(s)
2415 2416 2417
2418 2419
Editor Note 50: Sequential use cases or similar still need to be added.
Page 95

Mef 10.3

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Mef 10.3

Enviado por

Direitos autorais:

Formatos disponíveis

Ethernet Services Attributes Phase 3

10. Bandwidth Profile at the UNI

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

Ethernet Services Attributes Phase 3

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

Coupling Flag per Bandwidth Profile Flow (CFi).

Color Mode per Bandwidth Profile Flow (CMi).

Ethernet Services Attributes Phase 3

Ethernet Services Attributes Phase 3

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

CIR i i T (t1 , t 2 ) = (t 2 t1 ) + S C+1 (t1 , t 2 ) 8

2178 2179 2180 2181

2183 2184 2185

2186 2187 2188 2189 2190 2191 2192

2193 2194 2195

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

Service Frame of length l j arrives at time t j for Bandwidth Profile Flow i j ( j 1)

[(CM == color - blind ) OR

Declare Service Frame Green BCj (t j ) = BCj (t j ) l j

No Declare Service Frame Red

Figure 28 The Bandwidth Profile Algorithm for an Envelope

2204 2205 2206 2207 2208 2209 2210

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

Bandwidth Profile without Sharing

2212 2213 2214

2218 2219 2220

CIR1 CIR1 1 (t 2 t1 ) min (t 2 t1 ), CBS 1 BC (t1 ) 8 8

1 CIR1 CIR1 (t 2 t1 ) CBS 1 min BC (t1 ) + (t 2 t1 ) CBS 1 ,0 8 8

1 CIR1 = max BC (t1 ) + (t 2 t1 ) CBS 1 ,0. 8

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

2229 2230 2231 2232

[(CM == color - blind ) OR

Declare Service Frame Green

No Declare Service Frame Red

2235 2236 2237

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

Ingress Bandwidth Profiles Service Attributes

2239 2240 2241 2242 2243 2244

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

2302 2303 2304 2305

Ethernet Services Attributes Phase 3

Bandwidth Profiles (Informative)

Visual Representation of the Bandwidth Profile

MEF 10.3 Working Draft 0.1.7

Ethernet Services Attributes Phase 3

CIR3 EIR3 CF3 0 1 EBS3

CIR2 EIR2 CF2 0 1 EBS2

CIR1 EIR1 CF1 0 0 CF0

2335 2336 2337

2338 2339 2340 2341 2342 2343 2344 2345

Ethernet Services Attributes Phase 3

CIR2 EIR2 CF2 1 EBS2

CIR1 EIR1 CF1 1 EBS1

2348 2349 2350

Figure 31 Bandwidth Profile Algorithm for Sharing Excess Bandwidth