idnits 2.17.1 draft-zhao-pce-pcep-extension-pce-controller-sr-00.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2017) is 2482 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 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-10 == Outdated reference: A later version (-05) exists of draft-ietf-teas-pce-central-control-03 == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-01 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-04 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-04 == Outdated reference: A later version (-08) exists of draft-zhao-pce-pcep-extension-for-pce-controller-04 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-09 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-17 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-01 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-08 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft Z. Li 4 Intended status: Standards Track D. Dhody 5 Expires: January 1, 2018 S. Karunanithi 6 Huawei Technologies 7 A. Farrel 8 Juniper Networks, Inc 9 C. Zhou 10 Cisco Systems 11 June 30, 2017 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of SR-LSPs 15 draft-zhao-pce-pcep-extension-pce-controller-sr-00 17 Abstract 19 In certain networks deployment scenarios, service providers would 20 like to keep all the existing MPLS functionalities in both MPLS and 21 GMPLS while removing the complexity of existing signalling protocols 22 such as LDP and RSVP-TE. PCE has been proposed to be used as a 23 central controller (PCECC) so that LSP can be calculated/setup/ 24 initiated and label forwarding entries are downloaded through a 25 centralized PCE server to each network devices along the path while 26 leveraging the existing PCE technologies as much as possible. 28 This document specifies the procedures and PCEP protocol extensions 29 when the PCE functions as one of the central controller components in 30 Segment Routing(SR). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 1, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. PCECC SR . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Procedures for Using the PCE as the Central Controller 72 (PCECC) in Segment Routing . . . . . . . . . . . . . . . . . 5 73 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 74 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 75 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 6 76 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 6 77 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 7 78 5.5.1. PCECC Segment Routing (SR) . . . . . . . . . . . . . 7 79 5.5.1.1. PCECC SR Node/Prefix Label allocation . . . . . . 7 80 5.5.1.2. PCECC SR Adjacency Label allocation . . . . . . . 8 81 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 9 82 5.5.1.4. Session Termination . . . . . . . . . . . . . . . 10 83 5.5.1.5. LABEL-DB Synchronization . . . . . . . . . . . . 10 84 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6.1. Label Operations . . . . . . . . . . . . . . . . . . . . 10 86 6.1.1. The PCLabelUpd message . . . . . . . . . . . . . . . 10 87 6.1.2. The PCLabelRpt message . . . . . . . . . . . . . . . 11 88 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 12 89 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 12 90 7.1.1. PCECC Capability TLV . . . . . . . . . . . . . . . . 12 91 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 13 92 7.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 13 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 94 9. Manageability Considerations . . . . . . . . . . . . . . . . 15 95 9.1. Control of Function and Policy . . . . . . . . . . . . . 15 96 9.2. Information and Data Models . . . . . . . . . . . . . . . 15 97 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 98 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 99 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 15 100 9.6. Impact On Network Operations . . . . . . . . . . . . . . 16 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 102 10.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 16 103 10.2. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 16 104 10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 16 105 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 108 12.2. Informative References . . . . . . . . . . . . . . . . . 18 109 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 20 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 112 1. Introduction 114 The Path Computation Element communication Protocol (PCEP) provides 115 mechanisms for Path Computation Elements (PCEs) to perform route 116 computations in response to Path Computation Clients (PCCs) requests. 117 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 118 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 119 enable active control of MPLS-TE and GMPLS tunnels. 121 [I-D.ietf-pce-pce-initiated-lsp] describes the setup and tear down of 122 PCE-initiated LSPs under the active stateful PCE model, without the 123 need for local configuration on the PCC, thus allowing for a dynamic 124 MPLS network that is centrally controlled and deployed. 126 [I-D.ietf-teas-pce-central-control] introduces the architecture for 127 PCE as a central controller, examines the motivations and 128 applicability for PCEP as a southbound interface, and introduces the 129 implications for the protocol. [I-D.ietf-teas-pcecc-use-cases] 130 describes the use cases for the PCECC architecture. 132 [I-D.zhao-pce-pcep-extension-for-pce-controller] specify the PCEP 133 extention for the PCE as the central controller (PCECC). This 134 document extends the PCECC procedures for Segment Routing (SR). 136 Segment Routing (SR) technology leverage the source routing and 137 tunnelling paradigms. A source node can choose a path without 138 relying on hop-by-hop signalling protocols such as LDP or RSVP-TE. 139 Each path is specified as a set of "segments" advertised by link- 140 state routing protocols (IS-IS or OSPF). 142 [I-D.ietf-spring-segment-routing] provides an introduction to SR 143 technology. The corresponding IS-IS and OSPF extensions are 144 specified in [I-D.ietf-isis-segment-routing-extensions] and 145 [I-D.ietf-ospf-segment-routing-extensions] , respectively. 147 A Segment Routed path (SR path) can be derived from an IGP Shortest 148 Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE 149 paths) may not follow IGP SPT. Such paths may be chosen by a 150 suitable network planning tool and provisioned on the source node of 151 the SR-TE path. 153 It is possible to use a stateful PCE for computing one or more SR-TE 154 paths taking into account various constraints and objective 155 functions. Once a path is chosen, the stateful PCE can instantiate 156 an SR-TE path on a PCC using PCEP extensions specified in 157 [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP 158 extensions described in [I-D.ietf-pce-segment-routing]. 160 PCECC may further use PCEP protocol for SR label distribution instead 161 of IGP extensions with some benefits. 163 The [I-D.zhao-pce-pcep-extension-for-pce-controller], specifies the 164 procedures and PCEP protocol extensions for using the PCE as one of 165 the the central controller components and user cases where LSPs are 166 calculated/setup/initiated and label forwarding entries are 167 downloaded on each hop along the path, through extending the existing 168 PCE architectures and PCEP. 170 This draft specify the procedures and PCEP protocol extensions for 171 using the PCE as the central controller for SR label distribution and 172 user cases where SR LSPs are calculated/setup/initiated/downloaded 173 through extending the existing PCE architectures and PCEP. 175 1.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 2. Terminology 183 Terminologies used in this document is same as described in the draft 184 [I-D.ietf-teas-pcecc-use-cases]. 186 3. PCECC SR 188 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 189 allow a stateful PCE to compute, update or initiate SR-TE paths. An 190 ingress node of an SR-TE path appends all outgoing packets with a 191 list of MPLS labels (SIDs). This is encoded in SR-ERO subobject, 192 capable of carrying a label (SID) as well as the identity of the 193 node/adjacency label (SID). 195 The notion of segment and SID is defined in 196 [I-D.ietf-spring-segment-routing], which fits the MPLS architecture 197 [RFC3031] as the label which is managed by a local allocation process 198 of LSR (similarly to other MPLS signaling protocols) 199 [I-D.ietf-spring-segment-routing-mpls]. The SR information such as 200 node/adjacency label (SID) is flooded via IGP as specified in 201 [I-D.ietf-isis-segment-routing-extensions] and 202 [I-D.ietf-ospf-segment-routing-extensions]. 204 As per [I-D.ietf-teas-pce-central-control], PCE as a central 205 controller can allocate and provision the node/adjacency label (SID) 206 via PCEP. 208 Rest of the processing is similar to existing stateful PCE with SR 209 mechanism. 211 For the purpose of this document, it is assumed that label range to 212 be used by a PCE is set on both PCEP peers. Further, a global label 213 range is assumed to be set on all PCEP peers in the SR domain. 215 4. PCEP Requirements 217 Following key requirements for PCECC-SR should be considered when` 218 designing the PCECC based solution: 220 o PCEP speaker supporting this draft MUST have the capability to 221 advertise its PCECC-SR capability to its peers. 223 o PCEP speaker not supporting this draft MUST be able to reject 224 PCECC-SR related message with a reason code that indicates no 225 support for PCECC. 227 o PCEP SHOULD provide a means to update (or cleanup) the label- map 228 entry to the PCC. 230 o PCEP SHOULD provide a means to synchronize the SR labels between 231 PCE to PCC in PCEP messages. 233 5. Procedures for Using the PCE as the Central Controller (PCECC) in 234 Segment Routing 236 5.1. Stateful PCE Model 238 Active stateful PCE is described in [I-D.ietf-pce-stateful-pce]. PCE 239 as a central controller (PCECC) reuses existing Active stateful PCE 240 mechanism as much as possible to control the LSP. 242 5.2. New LSP Functions 244 This document uses the same PCEP messages and its extenstions which 245 are described in [I-D.zhao-pce-pcep-extension-for-pce-controller] for 246 PCECC-SR as well. 248 PCEP messages PCRpt, PCInitiate, PCUpd are also used to send PCECC-SR 249 Reports, LSP setup and LSP update respectively. 251 PCLabelUpd message described in 252 [I-D.zhao-pce-pcep-extension-for-pce-controller] is used to download 253 or cleanup SR Label entry. 255 PCLabelRpt message described in 256 [I-D.zhao-pce-pcep-extension-for-pce-controller] is also used to 257 report the set of SR Label entries from PCC to PCE for which explicit 258 action is required from PCE (update or cleanup or do nothing for 259 these Label entries). 261 5.3. PCECC Capability Advertisement 263 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 264 advertise their support of PCECC extensions. A PCEP Speaker includes 265 the "PCECC Capability" TLV, described in 266 [I-D.zhao-pce-pcep-extension-for-pce-controller]. 268 A new S-bit is added in PCECC-CAPABILITY TLV to indicate support for 269 PCECC-SR. A PCC MUST set S-bit in PCECC-CAPABILITY TLV and include 270 SR-PCE-CAPABILITY TLV ([I-D.ietf-pce-segment-routing]) in OPEN Object 271 to support the PCECC SR extensions defined in this document. If 272 S-bit is set in PCECC-CAPABILITY TLV and SR-PCE-CAPABILITY TLV is not 273 advertised in OPEN Object, PCE SHOULD send a PCErr message with 274 Error-Type=19 (Invalid Operation) and Error-value=TBD(SR capability 275 was not advertised) and terminate the session. 277 5.4. PCEP session IP address and TEDB Router ID 279 PCE may construct its TEDB by participating in the IGP ([RFC3630] and 280 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 281 alternative is offered by BGP-LS [RFC7752] and 282 [I-D.dhodylee-pce-pcep-ls]. 284 PCEP [RFC5440] speaker MAY use any IP address while creating a TCP 285 session. It is important to link the session IP address with the 286 Router ID in TEDB for successful PCECC operations. 288 During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping 289 information. Thus a PCC includes the "Node Attributes TLV" 290 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 291 in the OPEN Object for this purpose. [RFC7752] describes the usage 292 as auxiliary Router-IDs that the IGP might be using, e.g., for TE 293 purposes. If there are more than one auxiliary Router-ID of a given 294 type, then multiple TLVs are used to encode them. 296 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 297 address is directly used for the mapping purpose. 299 5.5. LSP Operations 301 The PCEP messages pertaining to PCECC-SR MUST include PATH-SETUP-TYPE 302 TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly 303 identify the PCECC-SR LSP is intended. 305 5.5.1. PCECC Segment Routing (SR) 307 Segment Routing (SR) as described in 308 [I-D.ietf-spring-segment-routing] depends on "segments" that are 309 advertised by Interior Gateway Protocols (IGPs). The SR-node 310 allocates and advertises the SID (node, adj etc) and flood via the 311 IGP. This document proposes a new mechanism where PCE allocates the 312 SID (label) centrally and uses PCEP to advertise the SID. In some 313 deployments PCE (and PCEP) are better suited than IGP because of 314 centralized nature of PCE and direct TCP based PCEP session to the 315 node. 317 5.5.1.1. PCECC SR Node/Prefix Label allocation 319 Each node (PCC) is allocated a node-SID (label) by the PCECC. The 320 PCECC sends PCLabelUpd to update the label map of each node to all 321 the nodes in the domain. The TE router ID is determined from the 322 TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV 323 [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. 325 It is RECOMMENDED that PCEP session with PCECC SR capability to use a 326 different session IP address during TCP session establishment than 327 the node Router ID in TEDB, to make sure that the PCEP session does 328 not get impacted by the SR Node/Prefix Label maps (Section 5.4). 330 If a node (PCC) receives a PCLabelUpd message with a Label, out of 331 the range set aside for the global label, it MUST send a PCErr 332 message with Error-type=TBD (label download failure) and Error- 333 value=TBD (Label out of range) and MUST include the SRP object to 334 specify the error is for the corresponding label update 335 [I-D.zhao-pce-pcep-extension-for-pce-controller]. 337 On receiving the label map, each node (PCC) uses the local 338 information to determine the next-hop and download the label 339 forwarding instructions accordingly. The PCLabelUpd message in this 340 case MUST NOT have LSP object but uses new FEC object. 342 +---------+ +-------+ 343 |PCC | | PCE | 344 |192.0.2.3| +-------+ 345 +------| | | 346 | PCC +---------+ | 347 | 192.0.2.2| | | 348 +------| | | | 349 |PCC +----------+ | | 350 |192.0.2.1| | | | 351 +---------+ | | | 352 | | | | 353 |<------- PCLabelUpd, FEC=192.0.2.1---------------- | Label Map 354 | | | Label=X | update 355 |Find | | | 356 |Nexthop|<------- PCLabelUpd, FEC=192.0.2.1-------- | Label Map 357 |locally| | Label=X | update 358 | | | | 359 | | |<--- PCLabelUpd, FEC=192.0.2.1---- | Label Map 360 | | | Label=X | update 361 | | | | 363 The forwarding behaviour and the end result is similar to IGP based 364 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 365 ECMP-aware shortest-path forwarding of the packet towards the related 366 node. 368 PCE relies on the Node/Prefix Label cleanup using the same PCLabelUpd 369 message. 371 5.5.1.2. PCECC SR Adjacency Label allocation 373 [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE 374 to compute and initiate SR-TE paths, as well as a PCC to request a 375 path subject to certain constraint(s) and optimization criteria in SR 376 networks. 378 For PCECC SR, apart from node-SID, Adj-SID is used where each 379 adjacency is allocated an Adj-SID (label) by the PCECC. The PCECC 380 sends PCLabelUpd to update the label map of each Adj to the 381 corresponding nodes in the domain. Each node (PCC) download the 382 label forwarding instructions accordingly. Similar to SR Node/Prefix 383 Label allocation, the PCLabelUpd message in this case MUST NOT have 384 LSP object but uses new FEC object. 386 +---------+ +-------+ 387 |PCC | | PCE | 388 |192.0.2.3| +-------+ 389 +------| | | 390 | PCC +---------+ | 391 | 192.0.2.2| | | 392 +------| | | | 393 |PCC +----------+ | | 394 |192.0.2.1| | | | 395 +---------+ | | | 396 | | | | 397 |<------ PCLabelUpd, FEC=192.0.2.1 / ------------ | Label Map 398 | | | 192.0.2.2 | update 399 | | | Label=A | 400 | | | | 401 | |<----- PCLabelUpd, FEC=192.0.2.2------- | Label Map 402 | | | 192.0.2.1 | update 403 | | | Label=B | 404 | | | | 406 The forwarding behavior and the end result is similar to IGP based 407 "Adj-SID" in SR. 409 The Path Setup Type for segment routing MUST be set for PCECC SR (see 410 Section 7.2). All PCEP procedures and mechanism are similar to 411 [I-D.ietf-pce-segment-routing]. 413 PCE relies on the Adj label cleanup using the same PCLabelUpd 414 message. 416 5.5.1.3. Redundant PCEs 418 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 419 between the stateful PCEs. The SR Labels allocated by a PCE should 420 also be synchronized among PCEs for PCECC SR state synchronization. 421 Note that the SR labels are downloaded independent to the PCECC LSP, 422 and remains intact till any topology change. The redundant PCEs MUST 423 have a common view of all SR labels allocated in the domain. 425 Incase the session to the PCE that allocated the SR labels is down, 426 similar to the LSP re-delegation mechanims, the SR labels are re- 427 delegated to a redundant PCE using the PCLabelRpt message. This is 428 done so that the SR labels remains intact and cosntant in case of 429 session disconnect. 431 5.5.1.4. Session Termination 433 [I-D.zhao-pce-pcep-extension-for-pce-controller] describes the action 434 needed for label provisioned for the Basic PCECC LSP on this 435 terminated session. Similarly actions should be applied for SR 436 Labels as well. 438 Additionally, if PCC has any alternate PCEP session with another PCE, 439 then PCC MUST deligate the SR labels of this session to this 440 alternate PCE in a sequence of PCLabelRpt message. PCE can accept it 441 and can send PCLabelUpd message to update or clean the label. 443 Extensions for PCLabelUpd and PCLabelRpt message for SR label are 444 described in Section 6.1. 446 5.5.1.5. LABEL-DB Synchronization 448 [I-D.zhao-pce-pcep-extension-for-pce-controller] describes LABEL-DB 449 Synchronization procedures needed for the labels provisioned for the 450 Basic PCECC LSP. Same procedures should be applied for SR labels as 451 well. 453 6. PCEP messages 455 As defined in [RFC5440], a PCEP message consists of a common header 456 followed by a variable-length body made of a set of objects that can 457 be either mandatory or optional. An object is said to be mandatory 458 in a PCEP message when the object must be included for the message to 459 be considered valid. For each PCEP message type, a set of rules is 460 defined that specify the set of objects that the message can carry. 461 An implementation MUST form the PCEP messages using the object 462 ordering specified in this document. 464 6.1. Label Operations 466 6.1.1. The PCLabelUpd message 468 Label Update Message (PCLabelUpd) defined in 469 [I-D.zhao-pce-pcep-extension-for-pce-controller] is extended to 470 update the label map at the PCC. 472 The format of the extended PCLabelUpd message is as follows: 474 ::= 475 476 Where: 477 ::= 478 [] 480 ::= (|) 482 Where: 484 ::= 485