idnits 2.17.1 draft-zhang-ccamp-flexible-grid-rsvp-te-ext-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 == Line 24 has weird spacing: '... months and ...' == Line 25 has weird spacing: '... at any time...' == Line 26 has weird spacing: '...ference mate...' == Line 622 has weird spacing: '... of these ...' == Line 623 has weird spacing: '...cluding thos...' == (3 more instances...) -- The document date (March 12, 2012) is 4427 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) == Missing Reference: 'RFC2205' is mentioned on line 444, but not defined == Unused Reference: 'WSON-PCE' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC6163' is defined on line 504, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-pce-wson-routing-wavelength-05 ** Downref: Normative reference to an Informational draft: draft-ietf-pce-wson-routing-wavelength (ref. 'WSON-PCE') == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-wson-signaling-02 ** Downref: Normative reference to an Informational RFC: RFC 6163 ** Downref: Normative reference to an Informational draft: draft-zhang-ccamp-sson-framework (ref. 'SSON-FWK') -- Possible downref: Non-RFC (?) normative reference: ref. 'G.FLEXIGRID' == Outdated reference: A later version (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-04 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet-Draft Huawei 3 Intended status: Standards Track Oscar Gonzalez de Dios 4 Telefonica 5 D. Ceccarelli 6 Ericsson 7 Expires: September 12, 2012 March 12, 2012 9 RSVP-TE Signaling Extensions in support of Flexible Grid 11 draft-zhang-ccamp-flexible-grid-rsvp-te-ext-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 12, 2012. 37 Abstract 39 This memo describes the signaling extensions of GMPLS control of 40 flexible grid network. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119 [RFC2119]. 48 Table of Contents 50 1. Introduction ................................................. 2 51 2. Terminology .................................................. 3 52 3. Requirements for Flexible Grid Signaling ..................... 3 53 3.1. Slot Width .............................................. 4 54 3.2. Frequency Slot .......................................... 4 55 4. Extensions ................................................... 5 56 4.1. SSON Traffic Parameters ................................. 5 57 4.2. Generalized Label ....................................... 6 58 4.3. Signaling Procedures .................................... 8 59 4.3.1. Distributed SA ..................................... 8 60 4.3.2. Centralized SA ..................................... 9 61 5. Example ...................................................... 9 62 6. IANA Considerations ......................................... 10 63 6.1. RSVP Objects Class Types ............................... 10 64 6.2. DWDM Channel Spacing ................................... 10 65 6.3. PCEP Object ............................................ 11 66 7. Security Considerations ..................................... 11 67 8. References .................................................. 11 68 8.1. Normative References ................................... 11 69 8.2. Informative References ................................. 12 70 9. Contributors' Address ....................................... 12 71 10. Authors' Addresses ......................................... 13 73 1. Introduction 75 [G.694.1v1] defines the DWDM frequency grids for WDM applications. A 76 frequency grid is a reference set of frequencies used to denote 77 allowed nominal central frequencies that may be used for defining 78 applications. The channel spacing, i.e. the frequency spacing 79 between two allowed nominal central frequencies can be 12.5 GHz, 25 80 GHz, 50 GHz, 100 GHz and integer multiples of 100 GHz as defined in 81 [G.694.1v1]. All of the wavelengths on a fiber SHALL use different 82 central frequencies and occupy a fixed bandwidth of frequency. 84 [G.FLEXIGRID], an updated version of [G.694.1v1] has be consented in 85 December 2011 in support of flexible grids. The terms "frequency 86 slot (i.e. the frequency range allocated to a specific channel and 87 unavailable to other channels within a flexible grid)" and "slot 88 width" (i.e. the full width of a frequency slot in a flexible grid) 89 are introduced to define a flexible grid. A channel is represented 90 as an LSC (Lambda Switching Capable) LSP in the control plane and 91 occupies a frequency slot on each fiber it traverses. In the case of 92 flexible grid, the different flexi-LSPs may have different slot 93 widths on a given fiber, referring to [SSON-FWK]. 95 [WSON-SIG] describes the requirements and extensions for WSON 96 signaling. It focuses on the control of optical networks using a 97 fixed DWDM grid. This document describes the additional requirements 98 and extensions for signaling of LSPs using the felxi-grid 99 capabilities. 101 2. Terminology 103 Flexi-grid: See [SSON-FWK]. 105 Slot Width: See [SSON-FWK]. 107 Frequency Range: See [SSON-FWK]. 109 SSON: Spectrum-Switched Optical Networks; See [SSON-FWK]. 111 flexi-LSP: See [SSON-FWK]. 113 RSA: See [SSON-FWK]. 115 3. Requirements for Flexible Grid Signaling 117 A flexi-LSP SHOULD occupy a frequency slot, i.e. a range of 118 frequencies. The process of computing a route and the allocation of 119 a frequency slot is referred to as RSA (Routing and Spectrum 120 Assignment). 122 [SSON-FWK] describes three types of architecture approaches to RSA, 123 which are: combined RSA, separated RSA and distributed SA. The first 124 two approaches among them could be called "centralized SA", since 125 both routing and spectrum (frequency slot) assignment are performed 126 by centralized entity before the signaling procedure. 128 In the case of centralized SA, the assigned frequency slot SHOULD be 129 specified in the Path message. In the case of distributed SA, the 130 slot width of the flexi-LSP SHOULD be specified in the Path message, 131 allowing the involved network elements (e.g., the egress node) to 132 perform such distributed assignment. 134 Similar to a fixed grid network, if the capability of shifting or 135 converting the whole optical spectrum allocated to a flexi-LSP is 136 not available, the flexi-LSP is subject to the Optical "Spectrum 137 Continuity Constraint", as described in [SSON-FWK]. 139 3.1. Slot Width 141 The slot width is an end-to-end parameter representing how much 142 frequency resource is requested for a flexi-LSP. Since different 143 LSPs may request different amounts of frequency resource in flexible 144 grid networks, the slot width SHOULD be carried in the signaling 145 message, so that all the nodes along the LSP can know how much 146 frequency resource (including both central frequency and slot width) 147 will be allocated for the LSP. 149 3.2. Frequency Slot 151 The frequency slot information represents which part of the 152 frequency resource is allocated on each link for a flexi-LSP. This 153 information SHOULD be carried hop-by-hop in signaling message so 154 that each node can indicate its neighbor the resource reservation on 155 the link between them. 157 The frequency slot can be represented by the two parameters: central 158 frequency and slot width, as follows: 160 Frequency slot = [(central frequency) - (slot width)/2] ~ 161 [(central frequency) + (slot width)/2] 163 Since the slot width information is carried in the signaling message 164 (as described in Section 2.1), also the central frequency parameter 165 SHOULD be carried in the signaling message for frequency slot 166 determination. 168 As described in [G.FLEXIGRID], for the flexible DWDM grid, the 169 allowed frequency slots have a nominal central frequency (in THz) 170 defined by: 172 193.1 + n * 0.00625, where n is a positive or negative integer 173 including 0, and 0.00625 is the nominal central frequency 174 granularity in THz. 176 and a slot width defined by: 178 12.5 * m, where m is a positive integer and 12.5 is the slot width 179 granularity in GHz. 181 Applications may be defined where only a subset of the possible slot 182 widths and positions are required to be supported. For example, an 183 application could be defined where the nominal central frequency 184 granularity is 12.5 GHz (by only requiring values of n that are even) 185 and that only requires slot widths as a multiple of 25 GHz (by only 186 requiring values of m that are even). 188 Figure 1 shows an example of two flexi-LSPs traversing a link and 189 illustrates how to determine the frequency slot based on the central 190 frequency and slot width information. 192 Frequency Slot 1 Frequency Slot 2 193 ------------- ------------------- 194 | | | | 195 -9 -8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 196 ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--... 197 ------------- ------------------- 198 ^ ^ 199 Central F = 193.1THz Central F = 193.14375 THz 200 Slot width = 25 GHz Slot width = 37.5 GHz 202 Figure 1 - Two flexi-LSPs traverse a Link 204 The two wavelengths shown in figure 1 have the following meaning: 206 flexi-LSP 1: central frequency = 193.1 THz, slot width = 25 GHz. It 207 means the frequency slot [193.0875 THz, 193.1125 THz] is assigned to 208 this flexi-LSP. 210 flexi-LSP 2: central frequency = 193.14375 THz, slot width = 37.5 211 GHz. It means the frequency slot [193.125 THz, 193.1625 THz] is 212 assigned to this flexi-LSP. 214 Note that the frequency slots of two flexi-LSPs on a fiber MUST NOT 215 overlap with each other. 217 4. Extensions 219 This section defines the extensions of signaling for flexible grid. 221 4.1. SSON Traffic Parameters 223 As described in Section 2, the slot width represents how much 224 frequency resource is requested for a flexi-LSP, i.e., it describes 225 the end-to-end traffic profile of the LSP. Therefore, the slot width 226 SHOULD be regarded as a traffic parameter for a flexi-LSP. 228 The SSON traffic parameters are organized as follows: 230 0 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | m | Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 m (8 bits): the slot width is specified by m*12.5 GHz. 238 Note that the slot width of a fixed grid defined in [G.694.1v1] can 239 also be specified by m because the defined channel spacings (12.5 240 GHz, 25 GHz, 50 GHz, 100 GHz and integer multiples of 100 GHz) are 241 also the multiple of 12.5 GHz. Therefore, the traffic parameters are 242 general for SSON including both fixed grid (i.e. WSON) and flexible 243 grid. 245 The SSON traffic parameters are carried in the SENDER_TSPEC object 246 within a Path message and in the FLOWSPEC object within a Resv 247 message: 249 SSON SENDER_TSPEC: Class = 12, C-Type = to be assigned by IANA, 250 preferred 8. 252 SSON FLOWSPEC: Class = 9, C-Type = to be assigned by IANA, preferred 253 8. 255 4.2. Generalized Label 257 In the case of a flexible grid link, the allocated central frequency 258 is calculated as follows: 260 Central Frequency = (193.1 + n * 0.00625) THz 262 Where n can be a positive or negative integer, or 0. 264 The Generalized Label object is used to indicate the resource 265 reserved on a link. In Flexible Grid networks, it is used to 266 indicate which frequency slot is allocated on a link for the given 267 flexi-LSP. 269 Since the frequency slot assigned to a flexi-LSP can be determined 270 by the combination of [central frequency, slot width], while the 271 slot width of a flexi-LSP is specified in the traffic parameters, 272 the Label object just needs to carry the assigned central frequency. 274 Therefore, the wavelength label format defined in [RFC6205] can be 275 reused to specify the central frequency of a flexi-LSP, without any 276 change on the label format. 278 0 1 2 3 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |Grid | C.S. | Identifier | n | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 The meaning of Grid, Identifier and n fields are not changed. The 285 usage of the label format is also not changed. 287 According to [G.FLEXIGRID], flexible grid still belongs to DWDM, so 288 there is no need to introduce a new type of Grid, i.e., Grid=1 (ITU- 289 T DWDM) SHOULD be used for flexible grid. 291 In case of Grid=1 (ITU-T DWDM), according to [G.697v2.1], a new 292 value of C.S. is defined for flexible 6.25 GHz grid. The 293 C.S.(Channel Spacing) field is defined as follows: 295 +--------------+---------+ 296 |C.S. (GHz) | Value | 297 +--------------+---------+ 298 | Reserved | 0 | 299 +--------------+---------+ 300 | 100 | 1 | 301 +--------------+---------+ 302 | 50 | 2 | 303 +--------------+---------+ 304 | 25 | 3 | 305 +--------------+---------+ 306 | 12.5 | 4 | 307 +--------------+---------+ 308 |Flexible grid | 5 (TBA) | 309 +--------------+---------+ 310 |Future use | 6 ~ 15 | 311 +--------------+---------+ 313 The frequency is calculated as such in [G.FLEXIGRID]: 315 Frequency (THz) = 193.1 THz + n * channel spacing (THz) 316 For the case where the channel spacing value is set to "Flexible 317 grid", a channel spacing of 6.25 GHz MUST be used in the above 318 formula. 320 4.3. Signaling Procedures 322 This section describes the signaling procedures for distributed SA 323 and centralized SA (See [SSON-FWK]). 325 4.3.1. Distributed SA 327 In this case, only the route is provided by a PCE or ingress node 328 before the signaling procedure. The available central frequencies 329 SHALL be collected hop by hop and the egress node SHOULD select a 330 proper central frequency for the LSP. 332 After the route is computed, the ingress node SHOULD find out the 333 available central frequencies for the LSP on the next link of the 334 route. If the frequency slot does not overlap with the existing 335 flexi-LSPs, the central frequency is considered to be available for 336 the requesting flexi-LSP. 338 Then a Path message is sent to the next node on the route. The Path 339 message MUST contain a SSON SENDER_TSPEC object to specify the slot 340 width of the flexi-LSP. A LABEL_SET object SHALL be added to the 341 Path message, which contains the candidate central frequencies for 342 the LSP on the next link. 344 When an intermediate node receives a Path message, it can get the 345 slot width from the SSON SENDER_TSPEC object. Then it SHOULD find 346 the available central frequencies for the LSP on the next link of 347 the route similar to the ingress node. The common part of the two 348 available central frequency sets, i.e. the set received from the 349 Path message and the set of the next link, SHALL be selected as the 350 new available central frequency set for the LSP. If the new set is 351 null, the Path message SHALL be rejected by a PathErr message. 352 Otherwise, the LABEL SET object in the Path message SHALL be updated 353 according to the new set and the Path message is forwarded to the 354 next node on the route. 356 When an egress node receives a Path message, it SHOULD select an 357 available central frequency from the LABEL SET object based on local 358 policy and determine the frequency slot based on the slot width and 359 the selected central frequency (See section 2.2). Then a Resv 360 message is responded so that the nodes along the LSP can establish 361 the optical cross-connect based on the frequency slot determined by 362 the slot width in the traffic parameters and the central frequency 363 in the label. 365 4.3.2. Centralized SA 367 In this case, both of the route and the frequency slot are provided 368 by the PCE or ingress node. When signaling the LSP, the slot width 369 is carried in the traffic parameters, and the assigned central 370 frequency is carried in the Label ERO. When the nodes along the LSP 371 receive the Path message carrying this information, they can 372 determine the frequency slot by the slot width and the central 373 frequency, so that they can establish the optical cross-connect 374 based on the central frequency. The procedures of ERO and Label ERO 375 are the same as described in [RFC3209] and [RFC3473]. 377 5. Example 379 An example is provided as below. In this example, assume that there 380 are two links and three nodes for the network topology and a flex- 381 LSP is assumed to be created from Node N1 to Node N3. 383 +------+ link1 +------+ link2 +------+ 384 | N1 +----------+ N2 +----------+ N3 | 385 +------+ +------+ +------+ 387 Frequency resources on link1 (central frequency granularity = 12.5 388 GHz): 390 -9 -8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 391 ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--... 392 |--Available Frequency Range--| 394 Frequency resources on link2 (central frequency granularity = 12.5 395 GHz): 397 -8 -6 -4 -2 0 2 4 6 8 10 398 ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--... 399 |--Available Frequency Range--| 401 The symbol '+' represents the allowed nominal central frequency. The 402 symbol "--" represents a 6.25 GHz frequency unit. The number on the 403 top of the line represents the 'n' in the frequency calculation 404 formula (193.1 + n * 0.00625). The nominal central frequency is 405 193.1 THz when n equals zero. 407 A flexi-LSP establishment request: 409 o Source node: N1 410 o Sink node: N3 411 o Slot width: 25 GHz 413 The usable central frequencies set for the flexi-LSP is 414 [n=0,1,2,3,4,5,6] on link1. But on link2, because the central 415 frequency granularity is 12.5 GHz, The usable central frequencies 416 set for the flexi-LSP is [n=0,2,4]. 418 In the case of Centralized SA, PCE or ingress node (N1) could 419 allocate an available frequency slot to the flexi-LSP, e.g. n=2 and 420 slot width=50 Ghz. During the LSP setup procedures, the slot width 421 (50 GHz, i.e. m=4) should be specified in the traffic parameters 422 objects and the central frequency (n=2) should be specified in the 423 label objects. 425 6. IANA Considerations 427 6.1. RSVP Objects Class Types 429 This document introduces two new Class Types for existing RSVP 430 objects. IANA is requested to make allocations from the "Resource 431 ReSerVation Protocol (RSVP) Parameters" registry using the "Class 432 Names, Class Numbers, and Class Types" sub-registry. 434 Class Number Class Name Reference 435 ------------ ----------------------- --------- 436 9 FLOWSPEC [RFC2205] 438 Class Type (C-Type): 440 (TBA) SSON FLOWSPEC [This.I-D] 442 Class Number Class Name Reference 443 ------------ ----------------------- --------- 444 12 SENDER_TSPEC [RFC2205] 446 Class Type (C-Type): 448 (TBA) SSON SENDER_TSPEC [This.I-D] 450 6.2. DWDM Channel Spacing 452 The IANA has created a registry and manages the space of DWDM 453 Channel Spacing as described in section 5.2 of [RFC6205]. It is 454 requested that the IANA makes assignments from the DWDM Channel 455 Spacing. 457 Value Channel Spacing (GHz) Reference 458 ----- ------------------------- ---------- 459 TBA Flexible grid [This.I-D] 461 6.3. PCEP Object 463 This document introduces a new Object-Type for existing PCEP objects. 464 It is requested that the IANA makes an assignment from the object- 465 type of GENERALIZED-BANDWIDTH. 467 Object-Class Name Reference 468 ------------ ----------------------- --------- 469 TBA GENERALIZED-BANDWIDTH [GMPLS-PCE] 471 Object-Type: 473 (TBA) SSON [This.I-D] 475 7. Security Considerations 477 This document introduces no new security considerations to [RFC3473]. 479 8. References 481 8.1. Normative References 483 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 484 requirements levels", RFC 2119, March 1997. 486 [WSON-PCE] Y. Lee, G. Bernstein, Jonas Martensson, T. Takeda and T. 487 Tsuritani, "PCEP Requirements for WSON Routing and 488 Wavelength Assignment", draft-ietf-pce-wson-routing- 489 wavelength-05, July 2011. 491 [WSON-SIG] G. Bernstein, Sugang Xu, Y. Lee, G. Martinelli and 492 Hiroaki Harai, "Signaling Extensions for Wavelength 493 Switched Optical Networks", draft-ietf-ccamp-wson- 494 signaling-02, September 2011. 496 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 497 Tunnels", RFC3209, December 2001. 499 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 500 Switching (GMPLS) Signaling Resource ReserVation Protocol- 501 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 502 January 2003. 504 [RFC6163] Y. Lee, G. Bernstein and W. Imajuku, "Framework for GMPLS 505 and Path Computation Element (PCE) Control of Wavelength 506 Switched Optical Networks (WSONs)", RFC 6163, April 2011. 508 [RFC6205] T. Otani and D. Li, "Generalized Labels for Lambda-Switch- 509 Capable (LSC) Label Switching Routers", RFC 6205, March 510 2011. 512 [SSON-FWK] F.Zhang et al, "Framework for GMPLS and PCE Control of 513 Spectrum Switched Optical Networks" , draft-zhang-ccamp- 514 sson-framework, in progress. 516 [G.FLEXIGRID] Revised G.694.1 version 1.6, Consented in December 517 2011, ITU-T Study Group 15. 519 [GMPLS-PCE] C. Margaria, O. Gonzalez de Dios, Desarrollo, and F. 520 Zhang, "PCEP extensions for GMPLS", draft-ietf-pce-gmpls- 521 pcep-extensions-04, October 2011. 523 8.2. Informative References 525 [G.694.1v1] ITU-T Recommendation G.694.1, Spectral grids for WDM 526 applications: DWDM frequency grid, June 2002. 528 [G.697v2.1] Draft revised G.697 version 2.1, Consented in December 529 2011, ITU-T Study Group 15. 531 9. Contributors' Address 533 Ramon Casellas 534 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 535 Av. Carl Friedrich Gauss n7 536 Castelldefels, Barcelona 08860 537 Spain 539 Phone: 540 Email: ramon.casellas@cttc.es 542 10. Authors' Addresses 544 Fatai Zhang 545 Huawei Technologies 546 F3-5-B R&D Center, Huawei Base 547 Bantian, Longgang District 548 Shenzhen 518129 P.R.China 550 Phone: +86-755-28972912 551 Email: zhangfatai@huawei.com 553 Oscar Gonzalez de Dios 554 Telefonica Investigacion y Desarrollo 555 Emilio Vargas 6 556 Madrid, 28045 557 Spain 559 Phone: +34 913374013 560 Email: ogondio@tid.es 562 Felipe Jimenez Arribas 563 Telefonica Investigacion y Desarrollo 564 Emilio Vargas 6 565 Madrid, 28045 566 Spain 567 Email: felipej@tid.es 569 Daniele Ceccarelli 570 Ericsson 571 Via A. Negrone 1/A 572 Genova - Sestri Ponente 573 Italy 574 Email: daniele.ceccarelli@ericsson.com 576 Xiaobing Zi 577 Huawei Technologies 578 F3-5-B R&D Center, Huawei Base 579 Bantian, Longgang District 580 Shenzhen 518129 P.R.China 582 Phone: +86-755-28973229 583 Email: zixiaobing@huawei.com 584 Yi Lin 585 Huawei Technologies Co., Ltd. 586 F3-5-B R&D Center, Huawei Base, 587 Bantian, Longgang District 588 Shenzhen 518129 P.R.China 590 Phone: +86-755-28972914 591 Email: yi.lin@huawei.com 593 Intellectual Property 595 The IETF Trust takes no position regarding the validity or scope of 596 any Intellectual Property Rights or other rights that might be 597 claimed to pertain to the implementation or use of the technology 598 described in any IETF Document or the extent to which any license 599 under such rights might or might not be available; nor does it 600 represent that it has made any independent effort to identify any 601 such rights. 603 Copies of Intellectual Property disclosures made to the IETF 604 Secretariat and any assurances of licenses to be made available, or 605 the result of an attempt made to obtain a general license or 606 permission for the use of such proprietary rights by implementers or 607 users of this specification can be obtained from the IETF on-line 608 IPR repository at http://www.ietf.org/ipr 610 The IETF invites any interested party to bring to its attention any 611 copyrights, patents or patent applications, or other proprietary 612 rights that may cover technology that may be required to implement 613 any standard or specification contained in an IETF Document. Please 614 address the information to the IETF at ietf-ipr@ietf.org. 616 The definitive version of an IETF Document is that published by, or 617 under the auspices of, the IETF. Versions of IETF Documents that are 618 published by third parties, including those that are translated into 619 other languages, should not be considered to be definitive versions 620 of IETF Documents. The definitive version of these Legal Provisions 621 is that published by, or under the auspices of, the IETF. Versions 622 of these Legal Provisions that are published by third parties, 623 including those that are translated into other languages, should 624 not be considered to be definitive versions of these Legal 625 Provisions. 627 For the avoidance of doubt, each Contributor to the IETF Standards 628 Process licenses each Contribution that he or she makes as part of 629 the IETF Standards Process to the IETF Trust pursuant to the 630 provisions of RFC 5378. No language to the contrary, or terms, 631 conditions or rights that differ from or are inconsistent with the 632 rights and licenses granted under RFC 5378, shall have any effect 633 and shall be null and void, whether published or posted by such 634 Contributor, or included with or in such Contribution. 636 Disclaimer of Validity 638 All IETF Documents and the information contained therein are 639 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 640 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 641 SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 642 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 643 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN 644 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 645 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Full Copyright Statement 649 Copyright (c) 2010 IETF Trust and the persons identified as the 650 document authors. All rights reserved. 652 This document is subject to BCP 78 and the IETF Trust's Legal 653 Provisions Relating to IETF Documents 654 (http://trustee.ietf.org/license-info) in effect on the date of 655 publication of this document. Please review these documents 656 carefully, as they describe your rights and restrictions with 657 respect to this document. Code Components extracted from this 658 document must include Simplified BSD License text as described in 659 Section 4.e of the Trust Legal Provisions and are provided without 660 warranty as described in the Simplified BSD License.