idnits 2.17.1 draft-ietf-ccamp-inter-domain-rsvp-te-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1067. 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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3473, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3209, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 880 has weird spacing: '...message mess...' (Using the creation date from RFC3209, updated by this document, for RFC5378 checks: 1998-11-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2007) is 6068 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) ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Farrel (Editor) 2 Network Working Group Old Dog Consulting 3 Intended Status: Standards Track 4 Updates: RFC 3209, RFC 3473 A. Ayyangar 5 Expires: March 2008 Juniper Networks 7 JP. Vasseur 8 Cisco Systems, Inc. 10 September 2007 12 Inter domain Multiprotocol Label Switching (MPLS) and 13 Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions 15 draft-ietf-ccamp-inter-domain-rsvp-te-07.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes procedures and protocol extensions for the 43 use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) 44 signaling in Multiprotocol Label Switching Traffic Engineering 45 (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and 46 non-packet networks to support the establishment and maintenance of 47 Label Switched Paths that cross domain boundaries. 49 For the purpose of this document, a domain is considered to be any 50 collection of network elements within a common realm of address space 51 or path computation responsibility. Examples of such domains include 52 Autonomous Systems, IGP routing areas, and GMPLS overlay networks. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1 Conventions Used In This Document . . . . . . . . . . . . 3 58 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Signaling Overview . . . . . . . . . . . . . . . . . . . . . 4 60 2.1 Signaling Options . . . . . . . . . . . . . . . . . . . . 5 61 3. Procedures on the Domain Border Node . . . . . . . . . . . . . 6 62 3.1 Rules on ERO Processing . . . . . . . . . . . . . . . . . 7 63 3.2 LSP Setup Failure and Crankback . . . . . . . . . . . . . 9 64 3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 10 65 3.4 Notify Message Processing . . . . . . . . . . . . . . . . 10 66 4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 11 67 4.1 Control of Downstream Choice of Signaling Method . . . . . 11 68 5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 12 69 5.1 Fast Recovery Support Using MPLS-TE Fast Reroute . . . . . 12 70 5.1.1 Failure Within a Domain (Link or Node Failure) . . . . 13 71 5.1.2 Failure of Link at Domain Borders . . . . . . . . . . 13 72 5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 13 73 5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 14 74 6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 14 75 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 9.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 18 79 9.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 19 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 11.1 Normative References . . . . . . . . . . . . . . . . . . 19 83 11.2 Informative References . . . . . . . . . . . . . . . . . 20 84 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 The requirements for inter-area and inter-AS Multiprotocol Label 89 Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and 90 [RFC4216] respectively. Many of these requirements also apply to 91 Generalized MPLS (GMPLS) networks. The framework for inter-domain 92 MPLS-TE is provided in [RFC4726]. 94 This document presents procedures and extensions to Resource 95 Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the 96 setup and maintenance of traffic engineered Label Switched Paths (TE 97 LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The 98 signaling procedures described in this document are applicable to 99 MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all 100 LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as 101 described in [RFC3473]. 103 Three different signaling methods for inter-domain RSVP-TE signaling 104 are identified in [RFC4726]. Contiguous LSPs are 105 achieved using the procedures of [RFC3209] and [RFC3473] to create a 106 single end-to-end LSP that spans all domains. Nested LSPs are 107 established using the techniques described in [RFC4206] to carry the 108 end-to-end LSP in a separate tunnel across each domain. Stitched LSPs 109 are established using the procedures of [LSP-STITCHING] to construct 110 an end-to-end LSP from the concatenation of separate LSPs each 111 spanning a domain. 113 This document defines the RSVP-TE protocol extensions necessary to 114 control and select which of the three signaling mechanisms is used 115 for any one end-to-end inter-domain TE LSP. 117 For the purpose of this document, a domain is considered to be any 118 collection of network elements within a common realm of address space 119 or path computation responsibility. Examples of such domains include 120 Autonomous Systems, IGP areas, and GMPLS overlay networks 121 ([RFC4208]). 123 1.1. Conventions Used In This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 1.2. Terminology 131 AS: Autonomous System. 133 ASBR: Autonmous System Border Router. A router used to connect 134 together ASes of a different or the same Service Provider via one or 135 more Inter-AS links. 137 Bypass Tunnel: An LSP that is used to protect a set of LSPs passing 138 over a common facility. 140 ERO: Explicit Route Object. 142 FA: Forwarding Adjacency. 144 LSR: Label Switching Router. 146 MP: Merge Point. The node where bypass tunnels meet the protected 147 LSP. 149 NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which 150 bypasses a single link of the protected LSP. 152 NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, 153 which bypasses a single node of the protected LSP. 155 PLR: Point of Local Repair. The ingress of a bypass tunnel. 157 RRO: Record Route Object. 159 TE link: Traffic Engineering link. 161 2. Signaling Overview 163 The RSVP-TE signaling of a TE LSP within a single domain is described 164 in [RFC3209] and [RFC3473]. Inter-domain TE LSPs can be supported by 165 one of three options as described in [RFC4726] and set out in the 166 next section: 168 - contiguous LSPs 169 - nested LSPs 170 - stitched LSPs. 172 In fact, as pointed out in [RFC4726], any combination of these three 173 options may be used in the course of an end-to-end inter-domain LSP. 174 That is, the options should be considered as per-domain transit 175 options so that an end-to-end inter-domain LSP that starts in domain 176 A, transits domains B, C and D, and ends in domain E might use an LSP 177 that runs contiguously from the ingress in domain A, through domain B 178 to the border with domain C. Domain C might be transited using the 179 nested LSP option to reach the border with domain D, and domain D 180 might be transited using the stitched LSP option to reach the border 181 with domain E, from where a normal LSP runs to the egress. 183 This document describes the RSVP-TE signaling extensions required to 184 control which of the three signaling mechanisms is used and to select 185 which of the three signaling mechanisms is used. 187 The specific protocol extensions required to signal each LSP type are 188 described in other documents and are out of scope for this document. 189 Similarly, the routing extensions and path computation techniques 190 necessary for the establishment of inter-domain LSPs are out of 191 scope. An implementation of a transit LSR is unaware of the options 192 for inter-domain TE LSPs since it sees only TE LSPs. An 193 implementation of a domain border LSR has to decide what mechanisms 194 of inter-domain TE LSP support to include, but must in any case 195 support contiguous inter-domain TE LSPs since this is the default 196 mode of operation for RSVP-TE. Failure to support either or both of 197 nested LSPs or stitched LSPs, restricts the operators options, but 198 does not prevent the establishment of inter-domain TE LSPs. 200 2.1. Signaling Options 202 There are three ways in which an RSVP-TE LSP could be signaled across 203 multiple domains: 205 Contiguous 206 A contiguous TE LSP is a single TE LSP that is set up across 207 multiple domains using RSVP-TE signaling procedures described in 208 [RFC3209] and [RFC3473]. No additional TE LSPs are required to 209 create a contiguous TE LSP and the same RSVP-TE information for 210 the TE LSP is maintained along the entire LSP path. In particular, 211 the TE LSP has the same RSVP-TE session and LSP ID at every LSR 212 along its path. 214 Nesting 215 One or more TE LSPs may be nested within another TE LSP as 216 described in [RFC4206]. This technique can be used to nest one 217 or more inter-domain TE LSPs into an intra-domain hierarchical LSP 218 (H-LSP). The label stacking construct is used to achieve nesting 219 in packet networks. In the rest of this document, the term H-LSP 220 is used to refer to an LSP that allows other LSPs to be nested 221 within it. An H-LSP may be advertised as a TE link within the same 222 instance of the routing protocol as was used to advertise the TE 223 links from which it was created, in which case it is a Forwarding 224 Adjacency (FA) [RFC4206]. 226 Stitching 227 The concept of LSP stitching as well as the required signaling 228 procedures is described in [LSP-STITCHING]. This technique can be 229 used to stitch together shorter LSPs (LSP segments) to create a 230 single, longer LSP. The LSP segments of an inter-domain LSP may be 231 intra-domain LSPs or inter-domain LSPs. 233 The process of stitching in the data plane results in a single, 234 end-to-end contiguous LSP. But in the control plane each segment is 235 signaled as a separate LSP (with distinct RSVP sessions) and the 236 end-to-end LSP is signaled as yet another LSP with its own RSVP 237 session. Thus the control plane operation for LSP stitching is very 238 similar to that for nesting. 240 An end-to-end inter-domain TE LSP may be achieved using one or more 241 of the signaling techniques described. The choice is a matter of 242 policy for the node requesting LSP setup (the ingress) and policy for 243 each successive domain border node. On receipt of an LSP setup 244 request (RSVP-TE Path message) for an inter-domain TE LSP, the 245 decision of whether to signal the LSP contiguously or whether to nest 246 or stitch it to another TE LSP, depends on the parameters signaled 247 from the ingress node and on the configuration of the local node. 249 The stitching segment LSP or H-LSP used to cross a domain may be 250 pre-established or signaled dynamically based on the demand caused by 251 the arrival of the inter-domain TE LSP setup request. 253 3. Procedures on the Domain Border Node 255 Whether an inter-domain TE LSP is contiguous, nested, or stitched is 256 limited by the signaling methods supported by or configured on the 257 intermediate nodes, and it is usually the domain border nodes where 258 this restriction applies since other transit nodes are oblivious to 259 the mechanism in use. The ingress of the LSP may further restrict the 260 choice by setting parameters in the Path message when it is signaled. 262 When a domain border node receives the RSVP Path message for an 263 inter-domain TE LSP setup, it MUST carry out the following procedures 264 before it can forward the Path message to the next node along the 265 path: 267 1. Apply policies for the domain and the domain border node. These 268 policies may restrict the establishment of inter-domain TE LSPs. 269 In case of a policy failure, the node SHOULD fail the setup and 270 send a PathErr message with error code "Policy control failure"/ 271 "Inter-domain policy failure". 273 2. Determine the signaling method to be used to cross the domain. 274 If the ingress node of the inter-domain TE LSP has specified 275 restrictions on the methods to be used, these MUST be adhered 276 to. Within the freedom allowed by the ingress node, the domain 277 border node MAY choose any method according to local 278 configuration and policies. If no resultant signaling method is 279 available or allowed, the domain border node MUST send a PathErr 280 message with an error code as described in Section 4.1. 282 Thus, for example, an ingress may request a contiguous LSP 283 because it wishes to exert maximal control over the LSP's path 284 and to control when re-optimization takes place. But the 285 operator of a transit domain may decide (for example) that only 286 LSP stitching is allowed for exactly the reason that it gives 287 the operator the chance to reoptimize their own domain under 288 their own control. In this case, the policy applied at the entry 289 to the transit domain will result in the return of a PathErr 290 message and the ingress has a choice to: 291 - find another path avoiding the transit domain 292 - relax his requirements 293 - fail to provide the service. 295 3. Carry out ERO procedures as described in Section 3 in addition 296 to the procedures in [RFC3209] and [RFC3473]. 298 4. Perform any path computations as required to determine the path 299 across the domain and potentially to select the exit point from 300 the domain. 302 The path computation procedure is outside the scope of this 303 document. A path computation option is specified in 304 [INTER-DOMAIN-PD-PATH-COMP], and another option is to use a 305 Path Computation Element (PCE) [RFC4655]. 307 4a. In the case of nesting or stitching, either find an existing 308 intra-domain TE LSP to carry the inter-domain TE LSP or 309 signal a new one, depending on local policy. 311 In event of a path computation failure, a PathErr message SHOULD 312 be sent with error code "Routing Problem" using an error value 313 selected according to the reason for computation failure. A 314 domain border node MAY opt so silently discard the Path message 315 in this case as described in Section 8. 317 In the event of the receipt of a PathErr message reporting 318 signaling failure from within the domain or reported from a 319 downstream domain, the domain border node MAY apply crankback 320 procedures as described in Section 3.2. If crankback is not 321 applied, or is exhausted, the border node MUST continue with 322 PathErr processing as described in [RFC3209] and [RFC3473]. 324 In the event of successful processing of a Path or Resv message, 325 the domain border node MUST carry out RRO procedures as described 326 in Section 3.3. 328 3.1. Rules on ERO Processing 330 The ERO that a domain border node receives in the Path message was 331 supplied by the ingress node of the TE LSP and may have been updated 332 by other nodes (for example, other domain border nodes) as the Path 333 message was propagated. The content of the ERO depends on several 334 factors including: 336 - the path computation techniques used 337 - the degree of TE visibility available to the nodes performing 338 path computation 339 - policy at the nodes creating/modifying the ERO. 341 In general, H-LSPs and LSP segments are used between domain border 342 nodes, but there is no restriction on the use of such LSPs to span 343 multiple hops entirely within a domain. Therefore, the discussion 344 that follows may be equally applied to any node within a domain 345 although the term 'domain border node' continues to be used for 346 clarity. 348 When a Path message reaches the domain border node, the following 349 rules apply for ERO processing and for further signaling. 351 1. If there are any policies related to ERO processing for the 352 LSP, they MUST be applied and corresponding actions taken. For 353 example, there might be a policy to reject EROs that identify 354 nodes within the domain. In case of inter-domain LSP setup 355 failures due to policy failures related to ERO processing, the 356 node SHOULD issue a PathErr with error code "Policy control 357 failure"/"Inter-domain explicit route rejected", but MAY be 358 configured to silently discard the Path message or to return a 359 different error code for security reasons. 361 2. Section 8.2 of [RFC4206] describes how a node at the edge of a 362 region processes the ERO in the incoming Path message and uses 363 this ERO, to either find an existing H-LSP or signal a new H-LSP 364 using the ERO hops. This process includes adjusting the ERO 365 before sending the Path message to the next hop. These 366 procedures MUST be followed for nesting or stitching of 367 inter-domain TE LSPs. 369 3. If an ERO subobject identifies a TE link formed by the 370 advertisement of an H-LSP or LSP segment (whether numbered or 371 unnumbered), contiguous signaling MUST NOT be used. The node MUST 372 either use nesting or stitching according to the capabilities of 373 the LSP that forms the TE link, the parameters signaled in the 374 Path message, and local policy. If there is a conflict between the 375 capabilities of the LSP that forms the TE link indicated in the 376 ERO and the parameters on the Path message, the domain border node 377 SHOULD send a PathErr with error code "Routing Problem"/"ERO 378 conflicts with inter-domain signaling method", but MAY be 379 configured to silently discard the Path message or to return a 380 different error code for security reasons. 382 4. An ERO in a Path message received by a domain border node may 383 have a loose hop as the next hop. This may be an IP address or 384 an AS number. In such cases, the ERO MUST be expanded to 385 determine the path to the next hop using some form of path 386 computation that may, itself, generate loose hops. 388 5. In the absence of any ERO subobjects beyond the local domain 389 border node, the LSP egress (the destination encoded in the RSVP 390 Session object) MUST be considered as the next loose hop and 391 rule 4 applied. 393 6. In the event of any other failures processing the ERO, a PathErr 394 message SHOULD be sent as described in [RFC3209] or [RFC3473], but 395 a domain border router MAY be configured to silently discard the 396 Path message or to return a different error code for security 397 reasons. 399 3.2. LSP Setup Failure and Crankback 401 When an error occurs during LSP setup a PathErr message is sent back 402 towards the LSP ingress node to report the problem. If the LSP 403 traverses multiple domains, this PathErr will be seen successively by 404 each domain border node. 406 Domain border nodes MAY apply local policies to restrict the 407 propagation of information about the contents of the domain. For 408 example, a domain border node MAY replace the information in a 409 PathErr message that indicates a specific failure at a specific node 410 with information that reports a more general error with the entire 411 domain. These procedures are similar to those described for the 412 borders of overlay networks in [RFC4208]. 414 However: 416 - A domain border node MUST NOT suppress the propagation of a PathErr 417 message except to attempt rerouting as described below. 419 - Nodes other than domain border nodes SHOULD NOT modify the contents 420 of a PathErr message. 422 - Domain border nodes SHOULD NOT modify the contents of a PathErr 423 message unless domain confidentiality is a specific requirement. 425 Domain border nodes provide an opportunity for crankback rerouting 426 [RFC4920]. On receipt of a PathErr message generated because of an 427 LSP setup failure, a domain border node MAY hold the PathErr and make 428 further attempts to establish the LSP if allowed by local policy and 429 by the parameters signaled on the Path message for the LSP. Such 430 attempts might involve the computation of alternate routes through 431 the domain, or the selection of different downstream domains. If a 432 subsequent attempt is successful, the domain border router MUST 433 discard the held PathErr message, but if all subsequent attempts are 434 unsuccessful, the domain border router MUST send the PathErr upstream 435 toward the ingress node. In this latter case, the domain border 436 router MAY change the information in the PathErr message to provide 437 further crankback details and information aggregation as described 438 in [RFC4920]. 440 Crankback rerouting MAY also be used to handle the failure of LSPs 441 after they have been established [RFC4920]. 443 3.3. RRO Processing Across Domains 445 [RFC3209] defines the RRO as an optional used for loop detection and 446 for providing information about the hops traversed by LSPs. 448 As described for overlay networks in [RFC4208], a domain border node 449 MAY filter or modify the information provided in an RRO for 450 confidentiality reasons according to local policy. For example, a 451 series of identifiers of hops within a domain MAY be replaced with 452 the domain identifier (such as the AS number) or be removed entirely 453 leaving just the domain border nodes. 455 Note that a domain border router MUST NOT mask its own presence, and 456 MUST include itself in the RRO. 458 Such filtering of RRO information does not hamper the working of the 459 signaling protocol, but the subsequent information loss may render 460 management diagnostic procedures inoperable or at least make them 461 more complicated requiring the coordination of administrators of 462 multiple domains. 464 Similarly protocol procedures that depend on the presence of RRO 465 information may become inefficient. For example, the fast reroute 466 procedures defined in [RFC4090] use information in the RRO to 467 determine the labels to use and the downstream MP. 469 3.4. Notify Message Processing 471 Notify messages are introduced in [RFC3473]. They may be sent direct 472 rather than hop-by-hop, and so may speed the propagation of error 473 information. If a domain border router is interested in seeing 474 such messages (for example, to enable it to provide protection 475 switching), it is RECOMMENDED that the domain border router update 476 the Notify Request objects in the Path and Resv messages to show its 477 own address following the procedures of [RFC3473]. 479 Note that the replacement of a Notify Recipient in the Notify Request 480 object means that some Notify messages (for example, those intended 481 for delivery to the ingress LSR) may need to be examined, processed 482 and forwarded at domain borders. This is an obvious trade-off issue 483 as the ability to handle notifiable events locally (i.e. within the 484 domain) may or may not outweigh the cost of processing and forwarding 485 Notify messages beyond the domain. Observe that the cost increases 486 linearly with the number of domains in use. 488 Also note that, as described in section 8, a domain administrator may 489 wish to filter or modify Notify messages that are generated within a 490 domain in order to preserve security or confidentiality of network 491 information. This is most easily achieved if the Notify messages are 492 sent via the domain borders. 494 4. RSVP-TE Signaling Extensions 496 The following RSVP-TE signaling extensions are defined to enable 497 inter-domain LSP setup. 499 4.1. Control of Choice of Signaling Method 501 In many network environments there may be a network-wide policy that 502 determines which one of the three inter-domain LSP techniques is 503 used. In these cases, no protocol extensions are required. 505 However, in environments that support more than one technique, an 506 ingress node may wish to constrain the choice made by domain border 507 nodes for each inter-domain TE LSP that it originates. 509 [RFC4420] defines the LSP_Attributes object that can be used to 510 signal required attributes of an LSP. The Attributes Flags TLV 511 includes Boolean flags that define individual attributes. 513 This document defines a new bit in the TLV that can be set by the 514 ingress node of an inter-domain TE LSP to restrict the intermediate 515 nodes to using contiguous signaling. 517 Contiguous LSP bit (bit number assignment in Section 9.1). 519 This flag is set by the ingress node that originates a Path message 520 to set up an inter-domain TE LSP if it requires that the contiguous 521 LSP technique is used. This flag bit is only to be used in the 522 Attributes Flags TLV. 524 When a domain border LSR receives a Path message containing this bit 525 set (one), the node MUST NOT perform stitching or nesting in support 526 of the inter-domain TE LSP being set up. When this bit is clear 527 (zero), a domain border LSR MAY perform stitching or nesting 528 according to local policy. 530 This bit MUST NOT be modified by any transit node. 532 An intermediate node that supports the LSP_Attributes object and the 533 Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit, 534 but cannot support contiguous TE LSPs, MUST send a Path Error message 535 with an error code "Routing Problem"/"Contiguous LSP type not 536 supported" if it receives a Path message with this bit set. 538 If an intermediate node receiving a Path message with the "Contiguous 539 LSP" bit set in the Flags field of the LSP_Attributes, recognizes the 540 object, the TLV, and the bit and also supports the desired contiguous 541 LSP behavior, then it MUST signal a contiguous LSP. If the node is a 542 domain border node, or if the node expands a loose hop in the ERO, it 543 MUST include an RRO Attributes subobject in the RRO of the 544 corresponding Resv message (if such an object is present) with the 545 "Contiguous LSP" bit set to report its behavior. 547 Domain border LSRs MUST support and act on the setting of the 548 "Contiguous LSP" flag. 550 However, if the intermediate node supports the LSP_Attributes object 551 but does not recognize the Attributes Flags TLV, or supports the TLV 552 but does not recognize this "Contiguous LSP" bit, then it MUST 553 forward the object unmodified. 555 The choice of action by an ingress node that receives a PathErr when 556 requesting the use of a contiguous LSP is out of the scope of this 557 document, but may include the computation of an alternate path. 559 5. Protection and Recovery of Inter-Domain TE LSPs 561 The procedures described in Sections 3 and 4 MUST be applied to all 562 inter-domain TE LSPs, including bypass tunnels, detour LSPs 563 [RFC4090], and segment recovery LSPs [RFC4873]. This means that these 564 LSPs will also be subjected to ERO processing, policies, path 565 computation, etc. 567 Note also that the paths for these backup LSPs needs to be either 568 pre-configured, computed and signaled with the protected LSP, or 569 computed on-demand at the PLR. Just as with any inter-domain TE LSP, 570 the ERO may comprise of strict or loose hops, and will depend on the 571 TE visibility of the computation point into the subsequent domain. 573 If loose hops are required created in the path of the backup LSP, ERO 574 expansion will be required at some point along the path: probably at 575 a domain border node. In order that the backup path remains disjoint 576 from the protected LSP(s) the node performing the ERO expansion must 577 be provided with the path of the protected LSPs between the PLR and 578 the MP. This information can be gathered from the RROs of the 579 protected LSPs and is signaled in the DETOUR object for Fast Reroute 580 [RFC4090], and using route exclusion [RFC4874] for other protection 581 schemes. 583 5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) 585 [RFC4090] describes two methods for local protection for a 586 packet TE LSP in case of link, SRLG, or node failure. This section 587 describes how these mechanisms work with the proposed signaling 588 solutions for inter-domain TE LSP setup. 590 5.1.1. Failure Within a Domain (Link or Node Failure) 592 The mode of operation of MPLS-TE Fast Reroute to protect a 593 contiguous, stitched or nested TE LSP within a domain is identical to 594 the existing procedures described in [RFC4090]. Note that, in the 595 case of nesting or stitching, the end-to-end LSP is automatically 596 protected by the protection operation performed on the H-LSP or 597 stitching segment LSP. 599 No protocol extensions are required. 601 5.1.2. Failure of a Link at a Domain Borders 603 This cases arises where two domains are connected by a TE link. In 604 this case each domain has its own domain border node, and these two 605 nodes are connected by the TE link. An example of this case is where 606 the ASBRs of two ASes are connected by a TE link. 608 A contiguous LSP can be backed up using any PLR and MP, but if the 609 LSP uses stitching or nesting in either of the connected domains, the 610 PLR and MP MUST be domain border nodes for those domains. It will be 611 usual to attempt to use the local (connected by the failed link) 612 domain border nodes as the PLR and MP. 614 To protect an inter-domain link with MPLS-TE Fast Reroute, a set of 615 backup tunnels must be configured or dynamically computed between the 616 PLR and MP such that they are diversely routed from the protected 617 inter-domain link and the protected inter-domain LSPs. 619 Each protected inter-domain LSP using the protected inter-domain TE 620 link must be assigned to an NHOP bypass tunnel that is diverse from 621 the protected LSP. Such an NHOP bypass tunnel can be selected by 622 analyzing the RROs in the Resv messages of the available bypass 623 tunnels and the protected TE LSP. It may be helpful to this process 624 if the extensions defined in [RFC4561] are used to clearly 625 distinguish nodes and links in the RROs. 627 5.1.3. Failure of a Border Node 629 Two border node failure cases exist. If the domain border falls on a 630 link as described in the previous section, the border node at either 631 end of the link may fail. Alternatively, if the border falls on a 632 border node (as is the case with IGP areas) that single border node 633 may fail. 635 It can be seen that if stitching or nesting are used, the failed node 636 will be the start or end (or both) or a stitching segment LSP or 637 H-LSP in which case, protection must be provided to the far end of 638 stitching segment or H-LSP. Thus, where one of these two techniques 639 is in use, the PLR will be the upstream domain entry point in the 640 case of the failure of the domain exit point, and the MP will be the 641 downstream domain exit point in the case of the failure of the 642 domain entry point. Where the domain border falls at a single domain 643 border node, both cases will apply. 645 If the contiguous LSP mechanism is in use, normal selection of the 646 PLR and MP can be applied and any node within the domains may be used 647 to fill these roles. 649 As before, selection of a suitable backup tunnel (in this case an 650 NNHOP backup) must consider the paths of the backed up LSPs and the 651 available NNHOP tunnels by examination of their RROs. 653 Note that where the PLR is not immediately upstream of the failed 654 node, error propagation time may be delayed unless some mechanism 655 such as [BFD-MPLS] is implemented, or unless direct reporting, such 656 as through the GMPLS Notify message [RFC3473] is employed. 658 5.2. Protection and Recovery of GMPLS LSPs 660 [RFC4873] describes GMPLS based segment recovery. This allows 661 protection against a span failure, a node failure, or failure over 662 any particular portion of a network used by an LSP. 664 The domain border failure cases described in Section 5.1 may also 665 occur in GMPLS networks (including packet networks) and can be 666 protected against using segment protection without any additional 667 protocol extensions. 669 Note that if loose hops are used in the construction of the working 670 and protection paths signaled for segment protection then care is 671 required to keep these paths disjoint. If the paths are signaled 672 incrementally then route exclusion [RFC4874] may be used to ensure 673 that the paths are disjoint. Otherwise a coordinated path computation 674 technique such as that offered by cooperating Path Computation 675 Elements [RFC4655] can provide suitable paths. 677 6. Re-Optimization of Inter-Domain TE LSPs 679 Re-optimization of a TE LSP is the process of moving the LSP from the 680 current path to a more prefered path. This involves the determination 681 of the preferred path and make-before-break signaling procedures 682 [RFC3209] to minimize traffic disruption. 684 Re-optimization of an inter-domain TE LSP may require a new path in 685 more than one domain. 687 The nature of the inter-domain LSP setup mechanism defines how 688 re-optimization can be applied. If the LSP is contiguous then the 689 signaling of the make-before-break process MUST be initiated by the 690 ingress node as defined in [RFC3209]. But if the re-optimization is 691 limited to a change in path within one domain (that is, if there is 692 no change to the domain border nodes) and nesting or stitching are in 693 use, the H-LSP or stitching segment may be independently re-optimized 694 within the domain without impacting the end-to-end LSP. 696 In all cases, however, the ingress LSR may wish to exert control and 697 coordination over the re-optimization process. For example, a transit 698 domain may be aware of the potential for reoptimization, but not 699 bother because it is not worried by the level of service being 700 provided across the domain. But the cummulative effect on the 701 end-to-end LSP may cause the head-end to worry and trigger an 702 end-to-end reoptimization request (of course, the transit domain may 703 choose to ignore the request). 705 Another benefit to end-to-end reoptimization over per-domain 706 reoptimization for non-contiguous inter-domain LSPs is that 707 per-domain re-optimization is restricted to preserve the domain entry 708 and exit points (since to do otherwise would break the LSP!). But 709 end-to-end reoptimization is more flexible and can select new domain 710 border LSRs. 712 There may be different cost benefit analysis considerations to choose 713 between end-to-end reoptimization and per-domain reoptimization. The 714 greater the number of hops involved in the reoptimization, the higher 715 the risk of traffic disruption. The shorter the segment reoptimized, 716 the lower the chance of making a substantial improvement on the 717 qulaity of the end-to-end LSP. Administrative policies should be 718 applied in this area with care. 720 [RFC4736] describes mechanisms that allow: 722 - The ingress node to request each node with a loose next hop to 723 re-evaluate the current path in order to search for a more optimal 724 path. 726 - A node with a loose next hop to inform the ingress node that a 727 better path exists. 729 These mechanisms SHOULD be used for re-optimization of a contiguous 730 inter-domain TE LSP. 732 Note that end-to-end reoptimization may involve a non-local 733 modification and that might select new entry / exit points. In this 734 case, we can observe that local reoptimization is more easily and 735 flexibly achieved using nesting or stitching. Further, the "locality 736 principle" (i.e., the idea of keeping information only where it is 737 needed) is best achieved using stitching or nesting. That said, a 738 contiguous LSP can easily be modified to take advantage of local 739 reoptimizations (as defined in [RFC4736]) even if this would require 740 the dissemination of information and the invocation of signaling 741 outside the local domain. 743 7. Backward Compatibility 745 The procedures in this document are backward compatible with existing 746 deployments. 748 - Ingress LSRs are not required to support the extensions in this 749 document to provision intra-domain LSPs. The default behavior by 750 transit LSRs that receive a Path message that does not have the 751 "Contiguous LSP" bit set in the Attributes Flags TLV of the 752 LSP_Attribtes object or does not even have the object present is 753 to allow all modes of inter-domain TE LSP, so back-level ingress 754 LSRs are able to initiate inter-domain LSPs. 756 - Transit, non-border LSRs are not required to perform any special 757 processing and will pass the LSP_Attributes object onwards 758 unmodified according to the rules of [RFC2205]. Thus back-level 759 transit LSRs are fully supported. 761 - Domain border LSRs will need to be upgraded before inter-domain 762 TE LSPs are allowed. This is because of the need to establish 763 policy, administrative, and security controls before permitting 764 inter-domain LSPs to be signaled across a domain border. Thus 765 legacy domain border LSRs do not need to be considered. 767 The RRO additions in this document are fully backward compatible. 769 8. Security Considerations 771 RSVP does not currently provide for automated key management. 772 [RFC4107] states a requirement for mandatory automated key management 773 under certain situations. There is work starting in the IETF to 774 define improved authentication including automated key management for 775 RSVP. Implementations and deployments of RSVP should pay attention to 776 any capabilities and requirements that are outputs from this ongoing 777 work. 779 A separate document is being prepared to examine the security aspects 780 of RSVP-TE signaling with special reference to multi-domain 781 scenarios [MPLS-GMPLS-SEC]. [RFC4726] provides an overview of the 782 requirements for security in an MPLS-TE or GMPLS multi-domain 783 environment. 785 Before electing to utilise inter-domain signaling for MPLS-TE, the 786 administrators of neighboring domains MUST satisfy themselves of the 787 existence of a suitable trust relationship between the domains. In 788 the absence of such a relationship, the administrators SHOULD decide 789 not to deploy inter-domain signaling, and SHOULD disable RSVP-TE on 790 any inter-domain interfaces. 792 When signaling an inter-domain RSVP-TE LSP, an operator MAY make use 793 of the security features already defined for RSVP-TE [RFC3209]. This 794 may require some coordination between the domains to share the keys 795 (see [RFC2747] and [RFC3097]), and care is required to ensure that 796 the keys are changed sufficiently frequently. Note that this may 797 involve additional synchronization, should the domain border nodes 798 be protected with FRR, since the MP and PLR should also share the 799 key. 801 For an inter-domain TE LSP, especially when it traverses different 802 administrative or trust domains, the following mechanisms SHOULD be 803 provided to an operator (also see [RFC4216]): 805 1) A way to enforce policies and filters at the domain borders 806 to process the incoming inter-domain TE LSP setup requests 807 (Path messages) based on certain agreed trust and service 808 levels/contracts between domains. Various LSP attributes 809 such as bandwidth, priority, etc. could be part of such a 810 contract. 812 2) A way for the operator to rate-limit LSP setup requests 813 or error notifications from a particular domain. 815 3) A mechanism to allow policy-based outbound RSVP message 816 processing at the domain border node, which may involve 817 filtering or modification of certain addresses in RSVP 818 objects and messages. 820 Additionally, an operator may wish to reduce the signaling 821 interactions between domains to improve security. For example, the 822 operator might not trust the neighboring domain to supply correct or 823 trustable restart information [RSVP-RESTART] and might ensure that 824 the availablity of restart function is not configured in the Hello 825 message exchange across the domain border. Thus, suitable 826 configuration MUST be provided in an RSVP-TE implementation to 827 enable the operator to control optional protocol features that may be 828 considered a security risk. 830 Some examples of the policies described above are as follows: 832 A) An operator may choose to implement some kind of ERO filtering 833 policy on the domain border node to disallow or ignore hops 834 within the domain from being identified in the ERO of an 835 incoming Path message. That is, the policy is that a node 836 outside the domain cannot specify the path of the LSP inside the 837 domain. The domain border LSR can make implement this policy in 838 one of two ways: 840 - It can reject the Path message. 842 - It can ignore the hops in the ERO that lie within the domain. 844 B) In order to preserve confidentiality of network topology, an 845 operator may choose to disallow recording of hops within the 846 domain in the RRO or may choose to filter out certain recorded 847 RRO addresses at the domain border node. 849 C) An operator may require the border node to modify the addresses 850 of certain messages like PathErr or Notify originated from hops 851 within the domain. 853 D) In the event of a path computation failure, an operator may 854 require the border node to silently discard the Path message 855 instead of returning a PathErr. This is because a Path message 856 could be interpretted as a network probe, and a PathErr provides 857 information about the network capabilities and policies. 859 Note that the detailed specification of such policies and their 860 implementation are outside the scope of this document. 862 OAM mechanisms including [BFD-MPLS] and [RFC4379] are commonly used 863 to verify he connectivity of end-to-end LSPs and to trace their 864 paths. Where the LSPs are inter-domain LSPs, such OAM techniques MAY 865 require to be intercepted or modified at domain borders, or to be 866 passed transparently across domains. Further discussion of this topic 867 can be found in [INTERAS-PING] and [MPLS-GMPLS-SEC]. 869 9. IANA Considerations 871 IANA is requested to make the codepoint allocations described in the 872 following sections. 874 9.1. Attribute Flags for LSP_Attributes Object 876 A new bit is to be allocated from the "Attributes Flags" sub-registry 877 of the "RSVP TE Parameters" registry. 879 Path Resv RRO 880 Bit Name message message sub-object 881 ---- ------------------------------- -------- -------- ---------- 882 XX Contiguous LSP Yes No Yes 884 The value XX is to be defined by IANA. A value of 4 is suggested. 886 9.2. New Error Codes 888 New RSVP error codes/values are required to be allocated from the 889 "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry 890 of the "RSVP Parameters" registry. 892 For the existing error code "Policy control failure" (value 2), two 893 new error values are suggested as follows. The values are suggested 894 and are for IANA determination. 896 103 = Inter-domain policy failure 897 104 = Inter-domain explicit route rejected 899 For the existing error code "Routing Problem" (value 24), two new 900 error values are suggested as follows. The values are suggested and 901 are for IANA determination. 903 21 = Contiguous LSP type not supported 904 22 = ERO conflicts with inter-domain signaling method 906 10. Acknowledgements 908 The authors would like to acknowledge the input and helpful comments 909 from Kireeti Kompella on various aspects discussed in the document. 910 Deborah Brungard and Dimitri Papdimitriou provided thorough reviews. 912 Thanks to Sam Hartman for detailed discussions of the security 913 considerations. 915 11. References 917 11.1. Normative References 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, March 1997. 922 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 923 "Resource ReSerVation Protocol (RSVP) -- Version 1, 924 Functional Specification", RFC 2205, September 1997. 926 [RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels", 927 RFC 3209, December 2001. 929 [RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label 930 Switching (GMPLS) Signaling Resource ReserVation Protocol - 931 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 932 January 2003. 934 [RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized 935 MPLS TE", RFC 4206, October 2005. 937 [RFC4420] Farrel, A., et al, "Encoding of Attributes for 938 Multiprotocol Label Switching (MPLS) Label Switched Path 939 (LSP) Establishment Using RSVP-TE", RFC 4420, February 940 2006. 942 [LSP-STITCHING] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label 943 Switched Path Stitching with Generalized MPLS Traffic 944 Engineering", draft-ietf-ccamp-lsp-stitching, (work in 945 progress). 947 11.2. Informative References 949 [RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic 950 Authentication", RFC 2747, January 2000. 952 [RFC3097] Braden, R., and Zhang, L., "RSVP Cryptographic 953 Authentication -- Updated Message Type Value", RFC 3097, 954 April 2001. 956 [RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 957 for LSP Tunnels", RFC 4090, May 2005. 959 [RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements 960 for Inter-Area MPLS Traffic Engineering", RFC 4105, June 961 2005. 963 [RFC4107] Bellovin, S. and Housley, R., "Guidelines for Cryptographic 964 Key Management", BCP 107, RFC 4107, June 2005. 966 [RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the 967 Overlay Model", RFC 4208, October 2005. 969 [RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS) 970 Traffic Engineering (TE) Requirements", RFC 4216, November 971 2005. 973 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 974 Label Switched (MPLS) Data Plane Failures", RFC 4379, 975 February 2006. 977 [RFC4561] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of a 978 Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, 979 June 2006. 981 [RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation 982 Element (PCE)-Based Architecture", RFC 4655, August 2006. 984 [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A 985 Framework for Inter-Domain Multiprotocol Label Switching 986 Traffic Engineering", RFC 4726, November 2006. 988 [RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol Label 989 Switching (MPLS) Traffic Engineering (TE) Loosely Routed 990 Label Switched Path (LSP)", RFC 4736, November 2006. 992 [RFC4873] Berger, L., et al, "GMPLS Based Segment Recovery", 993 RFC 4873, May 2007. 995 [RFC4874] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude Routes - 996 Extension to Resource ReserVation Protocol-Traffic 997 Engineering (RSVP-TE)", RFC 4874, April 2007. 999 [RFC4920] Farrel, A., et al, "Crankback Signaling Extensions for 1000 MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. 1002 [BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs", 1003 draft-ietf-bfd-mpls, (work in progress). 1005 [INTERAS-PING] Nadeau, T., and Swallow, G., "Detecting MPLS Data 1006 Plane Failures in Inter-AS and inter-provider Scenarios", 1007 draft-nadeau-mpls-interas-lspping, work in progress. 1009 [INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and 1010 Zhang, R., "A Per-domain path computation method for 1011 computing Inter-domain Traffic Engineering (TE) Label 1012 Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd- 1013 path-comp, (work in progress). 1015 [MPLS-GMPLS-SEC] Luyuan Fang, et al., "Security Framework for MPLS 1016 and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- 1017 security-framework, work in progress. 1019 [RSVP-RESTART] Satyanarayana, A., and Rahman, R., "Extensions to 1020 GMPLS RSVP Graceful Restart", draft-ietf-ccamp-rsvp- 1021 restart-ext, work in progress. 1023 12. Authors' Addresses 1025 Adrian Farrel 1026 Old Dog Consulting 1028 E-mail: adrian@olddog.co.uk 1030 Arthi Ayyangar 1031 Juniper Networks, Inc. 1032 1194 N.Mathilda Ave 1033 Sunnyvale, CA 94089 1034 USA 1036 E-mail: arthi@juniper.net 1037 Jean Philippe Vasseur 1038 Cisco Systems, Inc. 1039 300 Beaver Brook Road 1040 Boxborough , MA - 01719 1041 USA 1043 Email: jpv@cisco.com 1045 Intellectual Property Statement 1047 The IETF takes no position regarding the validity or scope of any 1048 Intellectual Property Rights or other rights that might be claimed to 1049 pertain to the implementation or use of the technology described in 1050 this document or the extent to which any license under such rights 1051 might or might not be available; nor does it represent that it has 1052 made any independent effort to identify any such rights. Information 1053 on the procedures with respect to rights in RFC documents can be 1054 found in BCP 78 and BCP 79. 1056 Copies of IPR disclosures made to the IETF Secretariat and any 1057 assurances of licenses to be made available, or the result of an 1058 attempt made to obtain a general license or permission for the use of 1059 such proprietary rights by implementers or users of this 1060 specification can be obtained from the IETF on-line IPR repository at 1061 http://www.ietf.org/ipr. 1063 The IETF invites any interested party to bring to its attention any 1064 copyrights, patents or patent applications, or other proprietary 1065 rights that may cover technology that may be required to implement 1066 this standard. Please address the information to the IETF at ietf- 1067 ipr@ietf.org. 1069 Disclaimer of Validity 1071 This document and the information contained herein are provided on an 1072 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1073 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1074 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1075 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1076 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1077 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 Copyright Statement 1081 Copyright (C) The IETF Trust (2007). 1083 This document is subject to the rights, licenses and restrictions 1084 contained in BCP 78, and except as set forth therein, the authors 1085 retain all their rights.