idnits 2.17.1 draft-zhang-trill-multilevel-single-nickname-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3216 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '256' on line 436 -- Looks like a reference, but probably isn't: '257' on line 437 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Proposed Standard Donald Eastlake 4 Huawei 5 Radia Perlman 6 EMC 7 Margaret Wasserman 8 Painless Security 9 Hongjun Zhai 10 JIT 11 Expires: January 7, 2016 July 6, 2015 13 Single Area Border RBridge Nickname for TRILL Multilevel 14 draft-zhang-trill-multilevel-single-nickname-01.txt 16 Abstract 18 A major issue in multilevel TRILL is how to manage RBridge nicknames. 19 In this document, the area border RBridge uses a single nickname in 20 both Level 1 and Level 2. RBridges in Level 2 must obtain unique 21 nicknames but RBridges in different Level 1 areas may have the same 22 nicknames. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 63 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Nickname Handling on Border RBridges . . . . . . . . . . . . . 3 66 3.1. Actions on Unicast Packets . . . . . . . . . . . . . . . . 4 67 3.2. Actions on Multi-Destination Packets . . . . . . . . . . . 5 68 4. Per-flow Load Balancing . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Ingress Nickname Replacement . . . . . . . . . . . . . . . 6 70 4.2. Egress Nickname Replacement . . . . . . . . . . . . . . . . 7 71 5. Protocol Extensions for Discovery . . . . . . . . . . . . . . . 7 72 5.1. Discovery of Border RBridges in L1 . . . . . . . . . . . . 7 73 5.2. Discovery of Border RBridge Sets in L2 . . . . . . . . . . 8 74 6. One Border RBridge Connects Multiple Areas . . . . . . . . . . 8 75 7. E-L1FS/E-L2FS Backwards Compatibility . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. TRILL APPsub-TLVs . . . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Appendix A. Clarifications . . . . . . . . . . . . . . . . . . . . 10 83 A.1. Level Transition . . . . . . . . . . . . . . . . . . . . . 11 84 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 TRILL multilevel techniques are designed to improve TRILL scalability 89 issues. As described in [MultiL], there have been two proposed 90 approaches. One approach, which is referred as the "unique nickname" 91 approach, gives unique nicknames to all the TRILL switches in the 92 multilevel campus, either by having the Level-1/Level-2 border TRILL 93 switches advertise which nicknames are not available for assignment 94 in the area, or by partitioning the 16-bit nickname into an "area" 95 field and a "nickname inside the area" field. The other approach, 96 which is referred as the "aggregated nickname" approach, involves 97 assigning nicknames to the areas, and allowing nicknames to be reused 98 in different areas, by having the border TRILL switches rewrite the 99 nickname fields when entering or leaving an area. 101 The approach specified in this document is different from both 102 "unique nickname" and "aggregated nickname" approach. In this 103 document, the nickname of an area border RBridge is used in both 104 Level 1 (L1) and Level 2 (L2). No additional nicknames are assigned 105 to the L1 areas. Each L1 area is denoted by the group of all 106 nicknames of those border RBridges of the area. For this approach, 107 nicknames in L2 MUST be unique but nicknames inside different L1 108 areas MAY be reused. The use of the approach specified in this 109 document in one L1 area does not prohibit the use of other approaches 110 in other L1 areas in the same TRILL campus. 112 2. Acronyms and Terminology 114 2.1. Acronyms 116 Data Label: VLAN or FGL 118 IS-IS: Intermediate System to Intermediate System [ISIS] 120 2.2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 Familiarity with [RFC6325] is assumed in this document. 128 3. Nickname Handling on Border RBridges 130 This section provides an illustrative example and description of the 131 border learning border RBridge nicknames. 133 Area {2,20} level 2 Area {3,30} 134 +-------------------+ +-----------------+ +--------------+ 135 | | | | | | 136 | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 137 | 27 | | | | 44 | 138 | ----RB20--- ----RB30--- | 139 +-------------------+ +-----------------+ +--------------+ 141 Figure 3.1: An example topology for TRILL multilevel 143 In Figure 3.1, RB2, RB20, RB3 and RB30 are area border TRILL switches 144 (RBridges). Their nicknames are 2, 20, 3 and 30 respectively. Area 145 border RBridges use the set of border nicknames to denote the L1 area 146 that they are attached to. For example, RB2 and RB20 use nicknames 147 {2,20} to denote the L1 area on the left. 149 A source S is attached to RB27 and a destination D is attached to 150 RB44. RB27 has a nickname, say 27, and RB44 has a nickname, say 44 151 (and in fact, they could even have the same nickname, since the TRILL 152 switch nickname will not be visible outside these Level 1 areas). 154 3.1. Actions on Unicast Packets 156 Let's say that S transmits a frame to destination D and let's say 157 that D's location is learned by the relevant TRILL switches already. 158 These relevant switches have learned the following: 160 1) RB27 has learned that D is connected to nickname 3. 161 2) RB3 has learned that D is attached to nickname 44. 163 The following sequence of events will occur: 165 - S transmits an Ethernet frame with source MAC = S and destination 166 MAC = D. 168 - RB27 encapsulates with a TRILL header with ingress RBridge = 27, 169 and egress RBridge = 3 producing a TRILL Data packet. 171 - RB2 and RB20 have announced in the Level 1 IS-IS instance in area 172 {2,20}, that they are attached to all those area nicknames, 173 including {3,30}. Therefore, IS-IS routes the packet to RB2 (or 174 RB20, if RB20 on the least-cost route from RB27 to RB3). 176 - RB2, when transitioning the packet from Level 1 to Level 2, 177 replaces the ingress TRILL switch nickname with its own nickname, 178 so replaces 27 with 2. Within Level 2, the ingress RBridge field 179 in the TRILL header will therefore be 2, and the egress RBridge 180 field will be 3. (The egress nickname MAY be replaced with an area 181 nickname selected from {3,30}. See Section 4 for the detail of the 182 selection method. Here, suppose nickname 3 is used.) Also RB2 183 learns that S is attached to nickname 27 in area {2,20} to 184 accommodate return traffic. RB2 SHOULD synchronize with RB20 using 185 ESADI protocol [RFC7357] that MAC = S is attached to nickname 27. 187 - The packet is forwarded through Level 2, to RB3, which has 188 advertised, in Level 2, its L2 nickname as 3. 190 - RB3, when forwarding into area {3,30}, replaces the egress 191 nickname in the TRILL header with RB44's nickname (44). (The 192 ingress nickname MAY be replaced with an area nickname selected 193 from {2,20}. See Section 4 for the detail of the selection method. 194 Here, suppose nickname 2 is selected.) So, within the destination 195 area, the ingress nickname will be 2 and the egress nickname will 196 be 44. 198 - RB44, when decapsulating, learns that S is attached to nickname 2, 199 which is one of the area nicknames of the ingress. 201 3.2. Actions on Multi-Destination Packets 203 Distribution trees for flooding of multi-destination packets are 204 calculated separately within each L1 area and L2. When a multi- 205 destination packet arrives at the border, it needs to be transitioned 206 either from L1 to L2, or from L2 to L1. All border RBridges are 207 eligible for Level transition. However, for each multi-destination 208 packet, only one of them acts as the Designated Border RBridge (DBRB) 209 to do the transition while other non-DBRBs MUST drop the received 210 copies. All border RBridges of an area SHOULD agree on a pseudorandom 211 algorithm and locally determine the DBRB as they do in the "Per-flow 212 Load Balancing" section. It's also possible to implement a certain 213 election protocol to elect the DBRB. However, such kind of 214 implementations are out the scope of this document. 216 As per [RFC6325], multi-destination packets can be classified into 217 three types: unicast packet with unknown destination MAC address 218 (unknown-unicast packet), multicast packet and broadcast packet. Now 219 suppose that D's location has not been learned by RB27 or the frame 220 received by RB27 is recognized as broadcast or multicast. What will 221 happen, as it would in TRILL today, is that RB27 will forward the 222 packet as multi-destination, setting its M bit to 1 and choosing an 223 L1 tree, flooding the packet on the distribution tree, subject to 224 possible pruning. 226 When the copies of the multi-destination packet arrive at area border 227 RBridges, non-DBRBs MUST drop the packet while the DBRB, say RB2, 228 needs to do the Level transition for the multi-destination packet. 229 For a unknown-unicast packet, if the DBRB has learnt the destination 230 MAC address, it SHOULD convert the packet to unicast and set its M 231 bit to 0. Otherwise, the multi-destination packet will continue to be 232 flooded as multicast packet on the distribution tree. The DBRB 233 chooses the new distribution tree by replacing the egress nickname 234 with the new root RBridge nickname. The following sequence of events 235 will occur: 237 - RB2, when transitioning the packet from Level 1 to Level 2, 238 replaces the ingress TRILL switch nickname with its own nickname, 239 so replaces 27 with 2. RB2 also needs to replace the egress 240 RBridge nickname with the L2 tree root RBridge nickname, say 2. In 241 order to accommodate return traffic, RB2 records that S is 242 attached to nickname 27 and SHOULD use ESADI protocol to 243 synchronize this attachment information with other border RBridges 244 (say RB20) in the area. 246 - RB20, will receive the packet flooded on the L2 tree by RB2. It is 247 important that RB20 does not transition this packet back to L1 as 248 it does for a multicast packet normally received from another 249 remote L1 area. RB20 should examine the ingress nickname of this 250 packet. If this nickname is found to be a border RBridge nickname 251 of the area {2,20}, RB2 must not forwarded the packet into this 252 area. 254 - The packet is flooded on the Level 2 tree to reach both RB3 and 255 RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will 256 drop the packet. 258 - RB3, when forwarding into area {3,30}, replaces the egress 259 nickname in the TRILL header with the root RBridge nickname, say 260 3, of the distribution tree of L1 area {3,30}. (Here, the ingress 261 nickname MAY be replaced with an area nickname selected from 262 {2,20} as specified in Section 4.) Now suppose that RB27 has 263 learned the location of D (attached to nickname 3), but RB3 does 264 not know where D is. In that case, RB3 must turn the packet into a 265 multi-destination packet and floods it on the distribution tree of 266 L1 area {3,30}. 268 - RB30, will receive the packet flooded on the L1 tree by RB3. It is 269 important that RB30 does not transition this packet back to L2. 270 RB30 should also examine the ingress nickname of this packet. If 271 this nickname is found to be an L2 border RBridge nickname, RB30 272 must not transition the packet back to L2. 274 - The multicast listener RB44, when decapsulating the received 275 packet, learns that S is attached to nickname 2, which is one of 276 the area nicknames of the ingress. 278 4. Per-flow Load Balancing 280 Area border RBridges perform ingress/egress nickname replacement when 281 they transition TRILL data packets between Level 1 and Level 2. This 282 nickname replacement enables the per-flow load balance which is 283 specified as follows. 285 4.1. Ingress Nickname Replacement 287 When a TRILL data packet from other areas arrives at an area border 288 RBridge, this RBridge MAY select one area nickname of the ingress to 289 replace the ingress nickname of the packet. The selection is simply 290 based on a pseudorandom algorithm as defined in Section 5.3 of 291 [RFC7357]. With the random ingress nickname replacement, the border 292 RBridge actually achieves a per-flow load balance for returning 293 traffic. 295 All area border RBridges in an L1 area MUST agree on the same 296 pseudorandom algorithm. The source MAC address, ingress area 297 nicknames, egress area nicknames and the Data Label of the received 298 TRILL data packet are candidate factors of the input of this 299 pseudorandom algorithm. Note that the value of the destination MAC 300 address SHOULD be excluded from the input of this pseudorandom 301 algorithm, otherwise the egress RBridge will see one source MAC 302 address flip flopping among multiple ingress RBridges. 304 4.2. Egress Nickname Replacement 306 When a TRILL data packet originated from the area arrives at an area 307 border RBridge, this RBridge MAY select one area nickname of the 308 egress to replace the egress nickname of the packet. By default, it 309 SHOULD choose the egress area border RBridge with the least cost 310 route to reach. The pseudorandom algorithm as defined in Section 5.3 311 of [RFC7357] may be used as well. In that case, however, the ingress 312 area border RBridge may take the non-least-cost Level 2 route to 313 forward the TRILL data packet to the egress area border RBridge. 315 5. Protocol Extensions for Discovery 317 5.1. Discovery of Border RBridges in L1 319 The following Level 1 Border RBridge APPsub-TLV will be included in 320 an E-L1FS FS-LSP fragment zero [RFC7180bis] as an APPsub-TLV of the 321 TRILL GENINFO-TLV. Through listening to this Appsub-TLV, an area 322 border RBridge discovers all other area border RBridges in this area. 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type = L1-BORDER-RBRIDGE | (2 bytes) 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Length | (2 bytes) 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Sender Nickname | (2 bytes) 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 o Type: Level 1 Border RBridge (TRILL APPsub-TLV type tbd1) 334 o Length: 2 335 o Sender Nickname: The nickname the originating IS will use as the 336 L1 Border RBridge nickname. This field is useful because the 337 originating IS might own multiple nicknames. 339 5.2. Discovery of Border RBridge Sets in L2 341 The following APPsub-TLV will be included in an E-L2FS FS-LSP 342 fragment zero [RFC7180bis] as an APPsub-TLV of the TRILL GENINFO-TLV. 343 Through listening to this APPsub-TLV in L2, an area border RBridge 344 discovers all groups of L1 border RBridges and each such group 345 identifies an area. 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type = L1-BORDER-RB-GROUP | (2 bytes) 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Length | (2 bytes) 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | L1 Border RBridge Nickname 1 | (2 bytes) 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | ... | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | L1 Border RBridge Nickname k | (2 bytes) 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 o Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type tbd2) 361 o Length: 2*k. If length is not a multiple of 2, the APPsub-TLV is 362 corrupt and MUST be ignored. 364 o L1 Border RBridge Nickname: The nickname that an area border 365 RBridge uses as the L1 Border RBridge nickname. The L1-BORDER-RB- 366 GROUP TLV generated by an area border RBridge MUST include all L1 367 Border RBridge nicknames of the area. It's RECOMMENDED that these 368 k nicknames are ordered in ascending order according to the 2- 369 octet nickname considered as an unsigned integer. 371 When an L1 area is partitioned [MultiL], border RBridges will re- 372 discover each other in both L1 and L2 through exchanging LSPs. In L2, 373 the set of border RBridge nicknames for this splitting area will 374 change. Border RBridges that detect such a change MUST flush the 375 reach-ability information associated to any RBridge nickname from 376 this changing set. 378 6. One Border RBridge Connects Multiple Areas 380 It's possible that one border RBridge (say RB1) connects multiple L1 381 areas. RB1 SHOULD use a single area nickname for all these areas. 383 Nicknames used within one of these areas can be reused within other 384 areas. It's important that packets destined to those duplicated 385 nicknames are sent to the right area. Since these areas are connected 386 to form a layer 2 network, duplicated {MAC, Data Label} across these 387 areas ought not occur. Now suppose a TRILL data packet arrives at the 388 area border nickname of RB1. For a unicast packet, RB1 can lookup the 389 {MAC, Data Label} entry in its MAC table to identify the right 390 destination area (i.e., the outgoing interface) and the egress 391 RBridge's nickname. For a multicast packet: suppose RB1 is not the 392 DBRB, RB1 will not transition the packet; otherwise, RB1 is the DBRB, 394 - if this packet is originated from an area out of the connected 395 areas, RB1 should replicate this packet and flood it on the proper 396 Level 1 trees of all the areas in which it acts as the DBRB. 398 - if the packet is originated from one of the connected areas, RB1 399 should replicate the packet it receives from the Level 1 tree and 400 flood it on other proper Level 1 trees of all the areas in which 401 it acts as the DBRB except the originating area (i.e., the area 402 connected to the incoming interface). RB1 may also receive the 403 replication of the packet from the Level 2 tree. This replication 404 must be dropped by RB1. 406 7. E-L1FS/E-L2FS Backwards Compatibility 408 All Level 2 RBridges MUST support E-L2FS [RFC7356] [rfc7180bis]. The 409 Extended TLVs defined in Section 5 are to be used in Extended Level 410 1/2 Flooding Scope (E-L1FS/E-L2FS) PDUs. Area border RBridges MUST 411 support both E-L1FS and E-L2FS. RBridges that do not support either 412 E-L1FS or E-L2FS cannot serve as area border RBridges but they can 413 well appear in an L1 area acting as non-area-border RBridges. 415 8. Security Considerations 417 For general TRILL Security Considerations, see [RFC6325]. 419 The newly defined TRILL APPsub-TLVs in Section 5 are transported in 420 IS-IS PDUs whose authenticity can be enforced using regular IS-IS 421 security mechanism [ISIS][RFC5310]. This document raises no new 422 security issues for IS-IS. 424 9. IANA Considerations 426 9.1. TRILL APPsub-TLVs 428 IANA is requested to allocate two new types under the TRILL GENINFO 429 TLV [RFC7357] for the TRILL APPsub-TLVs defined in Section 5. The 430 following entries are added to the "TRILL APPsub-TLV Types under IS- 431 IS TLV 251 Application Identifier 1" Registry on the TRILL Parameters 432 IANA web page. 434 Type Name Reference 435 --------- ---- --------- 436 tbd1[256] L1-BORDER-RBRIDGE [This document] 437 tbd2[257] L1-BORDER-RB-GROUP [This document] 439 10. References 441 10.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997. 446 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 447 Ghanwani, "Routing Bridges (RBridges): Base Protocol 448 Specification", RFC 6325, July 2011. 450 [RFC7356] L. Ginsberg, S. Previdi, et al, "IS-IS Flooding Scope 451 LSPs", RFC 7356, June 2014. 453 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 454 Stokes, "Transparent Interconnection of Lots of Links 455 (TRILL): End Station Address Distribution Information 456 (ESADI) Protocol", RFC 7357, September 2014. 458 10.2. Informative References 460 [ISIS] ISO, "Intermediate system to Intermediate system routeing 461 information exchange protocol for use in conjunction with 462 the Protocol for providing the Connectionless-mode Network 463 Service (ISO 8473)", ISO/IEC 10589:2002. 465 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 466 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 467 RFC 5310, February 2009. 469 [RFC7180bis] D. Eastlake, M. Zhang, et al, "TRILL: Clarifications, 470 Corrections, and Updates", draft-eastlake-trill-rfc7180bis, 471 work in progress. 473 [MultiL] Perlman, R., Eastlake, D., et al, "Flexible Multilevel 474 TRILL", draft-perlman-trill-rbridge-multilevel, work in 475 progress. 477 Appendix A. Clarifications 478 A.1. Level Transition 480 It's possible that an L1 RBridge is only reachable from a non-DBRB 481 RBridge. If this non-DBRB RBridge refrains from Level transition, the 482 question is, how can a multicast packet reach this L1 RBridge? The 483 answer is, it will be reached after the DBRB performs the Level 484 transition and floods the packet using an L1 distribution tree. 486 Take the following figure as an example. RB77 is reachable from the 487 border RBridge RB30 while RB3 is the DBRB. RB3 transitions the 488 multicast packet into L1 and floods the packet on the distribution 489 tree rooted from RB3. This packet will finally flooded to RB77 via 490 RB30. 492 Area{3,30} 493 +--------------+ (root) RB3 o 494 | | \ 495 -RB3 | | o RB30 496 | | | / 497 -RB30-RB77 | RB77 o 498 +--------------+ 500 Example Topology L1 Tree 502 In the above example, the multicast packet is forwarded along a non- 503 optimal path. A possible improvement is to have RB3 configured not to 504 belong to this area. In this way, RB30 will surely act as the DBRB to 505 do the Level transition. 507 Author's Addresses 509 Mingui Zhang 510 Huawei Technologies 511 No.156 Beiqing Rd. Haidian District, 512 Beijing 100095 P.R. China 514 EMail: zhangmingui@huawei.com 516 Donald E. Eastlake, 3rd 517 Huawei Technologies 518 155 Beaver Street 519 Milford, MA 01757 USA 521 Phone: +1-508-333-2270 522 EMail: d3e3e3@gmail.com 524 Radia Perlman 525 EMC 526 2010 256th Avenue NE, #200 527 Bellevue, WA 98007 USA 529 EMail: radia@alum.mit.edu 531 Margaret Wasserman 532 Painless Security 534 EMail: mrw@painless-security.com 536 Hongjun Zhai 537 Jinling Institute of Technology 538 99 Hongjing Avenue, Jiangning District 539 Nanjing, Jiangsu 211169 China 541 EMail: honjun.zhai@tom.com