idnits 2.17.1 draft-ietf-mpls-tp-nm-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 23, 2009) is 5531 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'LM' on line 410 -- Looks like a reference, but probably isn't: 'DM' on line 410 -- Looks like a reference, but probably isn't: 'GAL-GACH' on line 823 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hing-Kam Lam 3 Internet Draft Alcatel-Lucent 4 Expires: August, 2009 Scott Mansfield 5 Intended Status: Informational Eric Gray 6 Ericsson 7 February 23, 2009 9 MPLS TP Network Management Requirements 10 draft-ietf-mpls-tp-nm-req-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance 15 with the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as "work 26 in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on August 23, 2009. 36 Abstract 38 This document specifies the requirements necessary to manage the 39 elements and networks that support an MPLS Transport Profile 40 (MPLS-TP). This document is a product of a joint International 41 Telecommunications Union - Telecommunications Standardization 42 Sector (ITU-T) and Internet Engineering Task Force (IETF) effort 43 to include a MPLS Transport Profile within the IETF MPLS 44 architecture. The requirements are driven by the management 45 functionality needs defined by ITU-T for packet transport 46 networks. 48 Table of Contents 50 1. Introduction................................................3 51 1.1. Terminology............................................3 52 2. Management Interface Requirements...........................4 53 3. Management Communication Channel (MCC) Requirements.........4 54 4. Management Communication Network (MCN) Requirements.........5 55 5. Fault Management Requirements...............................5 56 5.1. Supervision Function...................................5 57 5.2. Validation Function....................................7 58 5.3. Alarm Handling Function................................7 59 5.3.1. Alarm Severity Assignment.........................7 60 5.3.2. Alarm Suppression.................................8 61 5.3.3. Alarm Reporting Control...........................8 62 5.3.4. Alarm Reporting...................................8 63 6. Configuration Management Requirements.......................9 64 6.1. System Configuration...................................9 65 6.2. Control Plane Configuration............................9 66 6.3. Path Configuration.....................................9 67 6.4. Protection Configuration..............................10 68 6.5. OAM Configuration.....................................10 69 7. Performance Management Requirements........................11 70 7.1. Path Characterization Performance Metrics.............11 71 7.2. Performance Measurement Instrumentation..............12 72 7.2.1. Measurement Frequency............................12 73 7.2.2. Measurement Scope................................12 74 8. Security Management Requirements...........................13 75 8.1. Management Communication Channel Security.............13 76 8.1.1. Security of Management Communications............13 77 8.2. Signaling Communication Channel Security..............14 78 8.3. Data Channel Security.................................14 79 8.4. Distributed Denial of Service.........................14 80 9. Security Considerations....................................14 81 10. IANA Considerations.......................................15 82 11. Acknowledgments...........................................15 83 12. References................................................15 84 12.1. Normative References.................................15 85 12.2. Informative References...............................16 86 13. Author's Addresses........................................16 87 Copyright Statement...........................................17 88 Acknowledgment................................................17 89 APPENDIX A: Communication Channel (CC) Examples...............18 91 1. Introduction 93 This document describes the requirements necessary to manage the 94 elements and networks that support an MPLS Transport Profile 95 (MPLS-TP). It leverages the management requirements specified 96 in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701 97 [1] specifies generic management requirements for transport 98 (including packet-based and circuit-based) networks. RFC 4377 99 specifies the OAM requirements, including OAM-related network 100 management requirements, for MPLS networks. This document 101 expands on the requirements in [1] and [2] to cover fault, 102 configuration, performance, and security management for MPLS-TP 103 networks, and the requirements for object and information models 104 needed to manage MPLS-TP Networks and Network Elements. 106 1.1. Terminology 108 Although this document is not a protocol specification, the key 109 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in RFC 2119 [6] 112 and are to be interpreted as instructions to protocol designers 113 producing solutions that satisfy the requirements set out in 114 this document. 116 MPLS-TP NE: a network element (NE) that supports MPLS-TP 117 functions 119 MPLS-TP network: a network in which MPLS-TP NEs are deployed 121 Data Communication Network (DCN): a network that supports Layer 122 1 (physical layer), Layer 2 (data-link layer), and Layer 3 123 (network layer) functionality for distributed management 124 communications related to the management plane, for distributed 125 signaling communications related to the control plane, and other 126 operations communications (e.g., order-wire/voice 127 communications, software downloads, etc.). 129 Management Communication Network (MCN): A DCN supporting 130 management plane communication is referred to as a Management 131 Communication Network (MCN). 133 Signaling Communication Network (SCN): A DCN supporting control 134 plane communication is referred to as a Signaling Communication 135 Network (SCN). 137 Communication Channel (CC): a logical channel between network 138 elements (NEs) that can be used - e.g. - for management plane 139 application or control plane applications. The physical channel 140 supporting the CC is technology specific. See APPENDIX A: 142 Management Communication Channel (MCC): a CC dedicated for 143 management plane communications. 145 Signaling Communication Channel (SCC): a CC dedicated for 146 control plane communications. The SCC may be used for GMPLS/ASON 147 signaling and/or other control plane messages (e.g., routing 148 messages). 150 Operations System (OS): A system that performs the functions 151 that support processing of information related to operations, 152 administration, maintenance, and provisioning (OAM&P) for the 153 networks, including surveillance and testing functions to 154 support customer access maintenance. 156 2. Management Interface Requirements 158 This document does not specify which management interface 159 protocol should be the standard protocol for managing MPLS-TP 160 networks. Managing an end-to-end connection across multiple 161 operator domains where one domain is managed (for example) via 162 NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is 163 allowed. 165 For the management interface to the management system, an MPLS- 166 TP NE is not expected to actively support more than one 167 management protocol in any given deployment. The protocol to be 168 supported is at the discretion of the operator. 170 3. Management Communication Channel (MCC) Requirements 172 An MPLS-TP management network SHOULD support seamless management 173 connectivity with remote MPLS-TP domains and NEs as well as with 174 termination points located in NEs under control by a third party 175 network operator. See ITU-T G.8601 [8] for example scenarios in 176 multi-carrier multi-transport-technology environments. 178 For management purpose, every MPLS-TP NE MUST connect to an OS 179 either directly or indirectly via another MPLS-TP NE. When an 180 MPLS-TP NE is connected indirectly to an OS, an MCC MUST be 181 supported between the MPLS-TP NE and the other MPLS-TP NE. 183 4. Management Communication Network (MCN) Requirements 185 Entities of the MPLS-TP management plane communicate via a DCN, 186 or more specifically via the MCN. The MCN connects MPLS-TP NEs 187 with management systems, NEs with NEs, and management systems 188 with management systems. Transport DCN architecture and 189 requirements are specified in ITU-T G.7712/Y.1703 [7], including 190 network layer protocols and their interworking. 192 As a practical requirement, MCN connections require addressing. 193 See the section on addressing in [13] for further information. 195 In order to have the MCN operate properly, a number of 196 management functions for the MCN are required: 198 . Retrieval of DCN network parameters to ensure compatible 199 functioning, e.g. packet size, timeouts, quality of 200 service, window size, etc.; 202 . Establishment of message routing between DCN nodes; 204 . Management of DCN network addresses; 206 . Retrieval of operational status of the DCN at a given node; 208 . Capability to enable/disable access to the DCN. 210 5. Fault Management Requirements 212 The Fault Management functions within an MPLS-TP NE enable the 213 supervision, detection, validation, isolation, correction, and 214 reporting of abnormal operation of the MPLS-TP network and its 215 environment. 217 5.1. Supervision Function 219 The supervision function analyses the actual occurrence of a 220 disturbance or fault for the purpose of providing an appropriate 221 indication of performance and/or detected fault condition to 222 maintenance personnel and operations systems. 224 The MPLS-TP NE MUST support the following transmission 225 supervision functions: 227 . Supervision of continuity check functions used to detect a 228 broken connection; 230 . Supervision of connectivity check functions used to detect 231 misconnection; 233 . Supervision of looping check functions used to detect loops 234 in the data-plane forwarding path (which result in non- 235 delivery of traffic, wasting of forwarding resources and 236 unintended self-replication of traffic); 238 . Supervision of Alarms based on native OAM, e.g., AIS (Alarm 239 Indication Signal) and FDI (Forward Defect Indication) 241 . Supervision of traffic loss measurement in both directions 242 of the bidirectional connection; 244 . Supervision of Misinsertion check function used to detect 245 misinserted packet in the connection 247 . Supervision of Diagnostic test; 249 . Supervision of Route determination; 251 . Supervision of Remote defect indication; 253 . Supervision of the detection of failure in the sequence of 254 a protocol exchange (e.g. automatic protection switching 255 protocol); 257 . Supervision of client failure indication. 259 The MPLS-TP NE transmission-related supervision mechanisms MUST 260 support the flexibility to be configured to perform on-demand or 261 proactively. 263 The MPLS-TP NE MUST support supervision for software processing 264 e.g., processing fault, storage capacity problem, version 265 mismatch, Corrupted data, Out of memory, etc. 267 The MPLS-TP NE MUST support hardware-related supervision for 268 interchangeable and non-interchangeable units, cable, and power 269 problem. 271 The MPLS-TP NE SHOULD support environment-related supervision 272 for temperature, humidity, etc. 274 The MPLS-TP NE MUST support supervision of the OAM mechanisms 275 that are deployed for supporting the OAM requirements defined in 276 [3]. 278 5.2. Validation Function 280 Validation is concerned with the integration of Fault Causes 281 into Failures. A Fault Cause indicates a limited interruption of 282 the required transport function. A Fault Cause is not reported 283 to maintenance personnel because it could exist only for a very 284 short time. Note that some of these events however are summed up 285 in the Performance Monitoring process, and when this sum exceeds 286 a certain value, a Threshold Report can be generated. 288 When the Fault Cause lasts long enough, an inability to perform 289 the required transport function arises. This Failure condition 290 is subject to reporting to maintenance personnel and/or an OS 291 because corrective action might be required. Conversely, when 292 the Fault Cause ceases after a certain time, clearing of the 293 Failure condition is also subject to reporting. 295 The MPLS-TP NE MUST perform persistency checks on fault causes 296 before it declares a fault cause a failure. 298 A transmission failure SHALL be declared if the fault cause 299 persists continuously for a configurable time (Time-D). The 300 failure SHALL be cleared if the fault cause is absent 301 continuously for a configurable time (Time-C). Typically the 302 default time values would be as follows: 304 Time-D = 2.5 +/- 0.5 seconds 306 Time-C = 10 +/- 0.5 seconds 308 These time values are as defined in G.7710 [1]. 310 The failure declaration and clearing MUST be time stamped. The 311 time-stamp SHALL indicate the time at which the fault cause is 312 activated at the input of the fault cause persistency (i.e. 313 defect-to-failure integration) function, and the time at which 314 the fault cause is deactivated at the input of the fault cause 315 persistency function. 317 5.3. Alarm Handling Function 319 5.3.1. Alarm Severity Assignment 321 Failures might be categorized to indicate the severity or 322 urgency of the fault. 324 An MPLS-TP NE SHOULD support the flexibility of assignment of 325 severity (e.g., Critical, Major, Minor, Warning) by the 326 management system. 328 See G.7710 [1] for more description about alarm severity 329 assignment. 331 5.3.2. Alarm Suppression 333 Alarms may be generated from many sources, including OAM, device 334 status, etc. 336 An MPLS-TP NE MUST provide alarm suppression functionality that 337 prevents the generation of a superfluous alarms. 339 Examples of alarm suppression mechanisms include simply 340 discarding the alarms (or not generating them in the first 341 place), or aggregating the alarms together, thereby greatly 342 reducing the number of alarm notifications to be emitted. 344 Note: An MPLS-TP NE supporting the inter-working of one or more 345 networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with 346 MPLS-TP needs to translate an MPLS-TP fault into an existing 347 transport technology failure condition for reporting to the 348 management system. 350 See RFC 4377 [2] for more description. 352 5.3.3. Alarm Reporting Control 354 Alarm Reporting Control (ARC) supports an automatic in-service 355 provisioning capability. Alarm reporting MAY be turned off on a 356 per-managed entity (e.g., LSP) basis to allow sufficient time 357 for customer service testing and other maintenance activities in 358 an "alarm free" state. Once a managed entity is ready, alarm 359 reporting is automatically turned on. 361 An MPLS-TP NE SHOULD support the Alarm Reporting Control 362 function for controlling the reporting of alarm conditions. 364 See G.7710 [1] and RFC 3878 [9] for more description of ARC. 366 5.3.4. Alarm Reporting 368 Alarm Reporting is concerned with the reporting of relevant 369 events and conditions, which occur in the network (including the 370 NE, incoming signal, and external environment). 372 Local reporting is concerned with automatic alarming by means of 373 audible and visual indicators near the failed equipment. 375 An MPLS-TP NE MUST support local reporting of alarms. 377 The MPLS-TP NE MUST support reporting of alarms to an OS. These 378 reports are either autonomous reports (notifications) or reports 379 on request by maintenance personnel. The MPLS-TP ME SHOULD 380 report local (environmental) alarms to a network management 381 system. 383 6. Configuration Management Requirements 385 Configuration Management provides functions to identify, collect 386 data from, provide data to and control NEs. Specific 387 configuration tasks requiring network management support include 388 hardware and software configuration, configuration of NEs to 389 support transport paths (including required working and 390 protection paths), and configuration of required path 391 integrity/connectivity and performance monitoring (i.e. - OAM). 393 6.1. System Configuration 395 The MPLS-TP NE MUST support the configuration requirements 396 specified in G.7710 [1] for hardware, software, and date/time. 398 6.2. Control Plane Configuration 400 If a control plane is supported in an implementation of MPLS-TP, 401 the MPLS-TP NE MUST support the configuration of MPLS-TP control 402 plane functions by the management plane. Further detailed 403 requirements might be provided along with progress in defining 404 the MPLS-TP control plane in appropriate specifications. 406 6.3. Path Configuration 408 The MPLS-TP NE MUST support the capability of configuring 409 required path performance characteristic thresholds (e.g. - Loss 410 Measurement [LM], Delay Measurement [DM] thresholds). 412 The MPLS-TP NE MUST support the capability of configuring 413 required LSPs as follows: 415 . configure LSP indentifier and/or other information 416 necessary to retrieve LSP status information. 418 6.4. Protection Configuration 420 The MPLS-TP NE MUST support the capability of configuring 421 required path protection as follows: 423 . Designate specifically identified LSPs as working or 424 protection LSPs; 425 . define associations of working and protection paths; 426 . operate/release manual protection switching; 427 . operate/release force protection switching; 428 . operate/release protection lockout; 429 . set/retrieve Automatic Protection Switching (APS) 430 parameters, including - 431 . Wait to Restore time, 432 . Protection Switching threshold information. 434 6.5. OAM Configuration 436 The MPLS-TP NE MUST provide the capability to configure the OAM 437 entities and functions specified in [3]. 439 The MPLS-TP NE MUST support the capability to choose which OAM 440 functions to use and which maintenance entity to apply them. 442 The MPLS-TP NE MUST support the capability to configure the OAM 443 entities/functions as part of LSP setup, including bidirectional 444 point-to-point connections, associated uni-directional point-to- 445 point connections, and uni-directional point-to-multipoint 446 connections. 448 The MPLS-TP NE MUST support the configuration of maintenance 449 entity identifiers (e.g. MEP ID and MIP ID) for the purpose of 450 LSP connectivity checking. 452 The MPLS-TP NE MUST have the flexibility to configure OAM 453 parameters to meet their specific operational requirements, such 454 as whether (1) one-time on-demand immediately or (2) one-time 455 on-demand pre-scheduled or (3) on-demand periodically based on a 456 specified schedule or (4) proactive on-going. 458 The MPLS-TP NE MUST support the enabling/disabling of the 459 connectivity check processing. The connectivity check process of 460 the MPLS-TP NE MUST support provisioning of the identifiers to 461 be transmitted and the expected identifiers. 463 7. Performance Management Requirements 465 Performance Management provides functions to evaluate and report 466 upon the behavior of the equipment, NE, and network for the 467 purpose of Maintenance, Bring-into-service, Quality of service, 468 and Performance monitoring for signal degradation. ITU-T 469 Recommendation G.7710 [1] provides transport performance 470 monitoring requirements for packet-switched and circuit-switched 471 transport networks with the objective of providing coherent and 472 consistent interpretation of the network behavior, in particular 473 for hybrid network which consists of multiple transport 474 technologies. The performance management requirements specified 475 in this document are driven by such an objective. 477 7.1. Path Characterization Performance Metrics 479 The MPLS-TP NE MUST support collection of loss measurement (LM) 480 so that they can be used to detect performance degradation. 482 The MPLS-TP NE MUST support collection of delay measurement (DM) 483 so that they can be used to detect performance degradation. 485 The MPLS-TP NE MUST support reporting of Performance degradation 486 via fault management for corrective actions (e.g. protection 487 switching). 489 The MPLS-TP NE MUST support collection of loss ratio measurement 490 so that they can be used to determine Severely Errored Second 491 (SES). 493 A SES is declared for a one second interval when the ratio of 494 lost packets to total transmitted packets in that one second 495 interval exceeds a predetermined threshold. 497 The packet lost threshold for declaring SES MUST be 498 configurable. 500 The number of SESs MUST be collected per configurable intervals 501 (e.g. 15-minute and 24-hour). 503 The MPLS-TP NE MUST support collection of SES measurement so 504 that they can be used to determine service unavailable time. 506 A period of unavailable time (UAT) begins at the onset of 10 507 consecutive SES events. These 10 seconds are considered to be 508 part of unavailable time. A new period of available time begins 509 at the onset of 10 consecutive non-SES events. These 10 seconds 510 are considered to be part of available time. 512 The MPLS-TP NE MUST support collection of Unavailable Seconds 513 (UAS) so that they can be used to determine service 514 availability. 516 The number of UAS MUST be collected per configurable intervals 517 (e.g. 15-minute and 24-hour). 519 SES and UAS history (the number of readings to be retained and 520 available) is as defined in ITU and ANSI documents associated 521 with specific transport technologies (for instance, ITU-T 522 G.7710, and ANSI T1.231-2003 [T1.231.01-2003 for DSL,.02 for 523 DS1,.03 for DS3 and T1.231.04-2003 for SONET] - see [1] and [14] 524 respectively), however these are fairly consistently defined as 525 follows: 527 - Current and previous 1-day statistics 529 - Current and 16 recent 15-minute statistics (ITU-T) 531 - Current, previous and 31 recent 15-minute statistics (ANSI) 533 Note that - worst case (ANSI) requires 2 copies of 1-day 534 statistics (current and previous) and 33 copies of 15-minute 535 statistics (current, previous and 31 recent). 537 7.2. Performance Measurement Instrumentation 539 7.2.1. Measurement Frequency 541 The performance measurement mechanisms MUST support the 542 flexibility to be configured to operate on-demand or proactively 543 (i.e. continuously over a period of time). 545 7.2.2. Measurement Scope 547 On measurement of packet loss and loss ratio: 549 - For bidirectional P2P connections - 551 . on-demand measurement of single-ended packet loss, 552 and loss ratio, measurement are required; 554 . proactive measurement of packet loss, and loss 555 ratio, measurement for each direction are required. 557 - For associated unidirectional P2P connections - 559 . on-demand measurement of single-ended packet loss, 560 and loss ratio, measurement are required; 562 . proactive measurement of packet loss, and loss 563 ratio, measurement for each direction are required. 565 Note: for associated unidirectional P2P connections, this data 566 can only be measured at end-points. 568 - For unidirectional (P2P and P2MP) connection, proactive 569 measurement of packet loss, and loss ratio, are required. 571 On Delay measurement: 573 - For unidirectional (P2P and P2MP) connection, on-demand 574 measurement of delay measurement is required. 576 - For bidirectional (P2P) connection, on-demand measurement 577 of one-way and two-way delay are required. 579 8. Security Management Requirements 581 The MPLS-TP NE MUST support secure management and control 582 planes. 584 8.1. Management Communication Channel Security 586 Secure channels MUST be provided for all network traffic and 587 protocols used to support management functions. This MUST 588 include, at least, protocols used for configuration, monitoring, 589 configuration backup, logging, time synchronization, 590 authentication, and routing. The MCC MUST support application 591 protocols that provide confidentiality and data integrity 592 protection. 594 8.1.1. Security of Management Communications 596 If management communication security is provided, the MPLS-TP NE 597 MUST support the following: 599 - Use of open cryptographic algorithms (See RFC 3871 [5]) 601 - Authentication - allow management connectivity only from 602 authenticated entities. 604 - Authorization - allow management activity originated by an 605 authorized entity, using (for example) an Access Control 606 List (ACL). 608 Port Access Control - allow management activity received on an 609 authorized (management) port. 611 8.2.Signaling Communication Channel Security 613 Security considerations for the SCC are similar to the 614 considerations driving the requirements described in section 615 8.1. Security Requirements for the control plane are out of 616 scope for this document and are expected to be defined in the 617 appropriate control plane specifications. Management of the 618 control plane security must also be defined at that time. 620 8.3. Data Channel Security 622 8.4.Distributed Denial of Service 624 Denial of Service (DoS) attack is an attack which tries to 625 prevent a target from performing an assigned task, or providing 626 its intended service(s), through any means. A Distributed DoS 627 (DDoS) can multiply attack severity (possibly by an arbitrary 628 amount) by using multiple (potentially compromised) systems to 629 act as topologically (and potentially geographically) 630 distributed attack sources. It is possible to lessen the impact 631 and potential for DDOS by using secure protocols, turning off 632 unnecessary processes, logging and monitoring, and ingress 633 filtering. RFC 4732 [4] provides background on DOS in the 634 context of the Internet. 636 9. Security Considerations 638 Section 8 lists a set of security requirements that apply to 639 MPLS-TP network management. 641 Provisions to any of the network mechanisms designed to satisfy 642 the requirements described herein are required to prevent their 643 unauthorized use. Likewise, these network mechanisms MUST 644 provide a means by which an operator can prevent denial of 645 service attacks if those network mechanisms are used in such an 646 attack. 648 Solutions MUST provide mechanisms to prevent this private 649 information from being accessed by unauthorized eavesdropping, 650 or being directly obtained by an unauthenticated network 651 element, system or user. 653 Performance of diagnostic functions and path characterization 654 involves extracting a significant amount of information about 655 network construction that the network operator MAY consider 656 private. 658 10. IANA Considerations 660