idnits 2.17.1 draft-lihawi-ancp-protocol-access-extension-08.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 seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 32 instances of too long lines in the document, the longest one being 47 characters in excess of 72. -- The abstract seems to indicate that this document updates RFC6934, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC6320, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (1 April 2022) is 754 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5851' is mentioned on line 114, but not defined == Missing Reference: 'TR-156' is mentioned on line 410, but not defined == Unused Reference: 'RFC5515' is defined on line 612, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Li 3 Internet-Draft Huawei Technologies Co., Ltd. 4 Intended status: Experimental T. Haag 5 Expires: 3 October 2022 B. Witschurke 6 Deutsche Telekom 7 1 April 2022 9 Access Extensions for ANCP 10 draft-lihawi-ancp-protocol-access-extension-08 12 Abstract 14 The purpose of this document is to specify extensions to ANCP (Access 15 Node Control Protocol) (RFC6320) to support PON as described in 16 RFC6934 and some other DSL Technologies including G.fast. This 17 document updates RFC6320 by modifications to terminologies, flows and 18 specifying new TLV types. 20 This document updates RFC6320 by modifications to terminologies, 21 flows and specifying new TLV types. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 3 October 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Modification to ANCP - General Aspects . . . . . . . . . . . 4 65 4. Modification to DSL-Type TLV 0x0091 . . . . . . . . . . . . . 5 66 5. Extension to DSL Sub TLV . . . . . . . . . . . . . . . . . . 5 67 5.1. Expected Throughput (ETR) TLV . . . . . . . . . . . . . . 5 68 5.2. Attainable expected throughput (ATTETR) TLV . . . . . . . 6 69 5.3. Gamma Data Rate (GDR) TLV . . . . . . . . . . . . . . . . 6 70 5.4. Attainable Gamma Data Rate (ATTGDR) TLV . . . . . . . . . 6 71 6. ANCP-Based PON Topology Discovery . . . . . . . . . . . . . . 7 72 6.1. ANCP Port Up and Port Down Event Message Descriptions . . 7 73 6.2. PON Access Line Identification . . . . . . . . . . . . . 9 74 6.2.1. Access-Loop-Circuit-ID TLV . . . . . . . . . . . . . 9 75 6.2.2. Access-Loop-Remote-ID TLV . . . . . . . . . . . . . . 10 76 6.3. TLVs for PON Access Line Attributes . . . . . . . . . . . 10 77 6.3.1. PON-Access-Line-Attributes TLV . . . . . . . . . . . 10 78 6.3.2. PON-Access-Type TLV . . . . . . . . . . . . . . . . . 10 79 6.3.3. ONT/ONU-Average-Data-Rate-Downstream TLV . . . . . . 11 80 6.3.4. ONT/ONU-Peak-Data-Rate-Downstream TLV . . . . . . . . 11 81 6.3.5. ONT/ONU-Maximum-Data-Rate-Upstream TLV . . . . . . . 11 82 6.3.6. ONT/ONU-Assured-Data-Rate-Upstream TLV . . . . . . . 11 83 6.3.7. PON-Tree-Maximum-Data-Rate-Upstream TLV . . . . . . . 12 84 6.3.8. PON-Tree-Maximum-Data-Rate-Downstream TLV . . . . . . 12 85 6.3.9. Reserved TLV . . . . . . . . . . . . . . . . . . . . 12 86 6.3.10. Reserved TLV . . . . . . . . . . . . . . . . . . . . 12 87 7. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 12 88 7.1. ANCP TLV Type Registry . . . . . . . . . . . . . . . . . 12 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 10.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 RFC6934 introduces application of ANCP to PON. However, RFC6320 100 [RFC6320] haven't been updated to support PON. Besides, DSL 101 technology is also evolving. G.fast, VDSL2 Vectoring and VDSL2 Annex 102 Q were introduced as upgraded versions to provide higher bandwidths 103 for the last mile.. 105 This document considers all existing Access technologies used in a 106 Telco network, yet not supported by RFC6320 and specifies new TLVs 107 accordingly. 109 2. Terminology 111 This section repeats some definitions from RFC6320 and RFC6934 112 [RFC6934], but also updates some definitions where appropriate. 114 Access Node (AN): [RFC5851] Network device, usually located at a 115 service provider central office or street cabinet that terminates 116 access (local) loop connections from subscribers. In case the access 117 loop is a Digital Subscriber Line (DSL), the Access Node provides DSL 118 signal termination and is referred to as a DSL Access Multiplexer 119 (DSLAM). In case the access loop is a Passive Optical Network (PON), 120 the Access Node is referred to as an Optical Line Terminal (OLT). 122 Optical Line Terminal (OLT): is located in the service provider's 123 central office (CO) or street cabinet. It terminates and aggregates 124 multiple PONs (providing fiber access to multiple premises or 125 neighborhoods) on the subscriber side and interfaces with the Network 126 Access Server (NAS) that provides subscriber management. 128 Optical Network Terminal (ONT): terminates PON on the network side 129 and provides PON adaptation. The subscriber side interface and the 130 location of the ONT are dictated by the type of network deployment. 131 For an FTTP deployment (with fiber all the way to the apartment or 132 living unit), ONT has Ethernet (Fast Ethernet (FE) / Gigabit Ethernet 133 (GE) / Multimedia over Coax Alliance (MoCA)) connectivity with the 134 Home Gateway (HGW) / Customer Premises Equipment (CPE). In certain 135 cases, one ONT may provide connections to more than one Home Gateway 136 at the same time. 138 Optical Network Unit (ONU): a generic term denoting a device that 139 terminates any one of the distributed (leaf) endpoints of an Optical 140 Distribution Network (ODN), implements a PON protocol, and adapts PON 141 PDUs to subscriber service interfaces. In the case of a multi- 142 dwelling unit (MDU) or multi-tenant unit (MTU), a multi-subscriber 143 ONU typically resides in the basement or a wiring closet (FTTB case) 144 and has FE/GE/Ethernet over native Ethernet link or over xDSL 145 (typically VDSL2) connectivity with each CPE at the subscriber 146 premises. In the case where fiber is terminated outside the premises 147 (neighborhood or curb side) on an ONT/ONU, the last-leg-premises 148 connections could be via existing or new copper, with xDSL physical 149 layer (typically VDSL2). In this case, the ONU effectively is a 150 "PON-fed DSLAM". In new FTTdp based deployments the access node is 151 named DPU (Distribution Point Unit). Basically from ANCP perspective 152 this node provides the same functionality. Besides VDSL2, G.fast is 153 mature and widely deployed. 155 3. Modification to ANCP - General Aspects 157 ANCP message formats remain the same as described in section 3.5.1 of 158 RFC6320 when it is applied to PON. However, some message 159 descriptions need to be modified to make them applicable to variant 160 Access Networks, other than DSL specific. 162 The ANCP Adjacency message is extended to other Access Technologies 163 than DSL. Generalize the message format to following: 165 The following capabilities are defined for ANCP: 167 o Capability Type: Access Topology Discovery = 0x01 169 Access technology: ANY 171 Length (in bytes): 0 173 Capability Data: NULL 175 For the detailed protocol specification of this capability, see 176 Section 6 of RFC6320. 178 o Capability Type: Access Line Configuration = 0x02 180 Access technology: ANY 182 Length (in bytes): 0 184 Capability Data: NULL 186 For the detailed protocol specification of this capability, see 187 Section 7 of RFC6320. 189 o Capability Type: Access Remote Line Connectivity Testing = 0x04 190 Access technology: ANY 192 Length (in bytes): 0 194 Capability Data: NULL 196 For the detailed protocol specification of this capability, see 197 Section 8 of RFC6320. 199 4. Modification to DSL-Type TLV 0x0091 201 Add following new DSL-Type values. 203 Value: 32-bit unsigned integer 205 G.fast = 8 207 VDSL2 Annex Q = 9 209 SDSL bonded = 10 211 VDSL2 bonded = 11 213 G.fast bonded = 12 215 VDSL2 Annex Q bonded = 13 217 5. Extension to DSL Sub TLV 219 DSL sub TLVs are listed in Section 6.5 of RFC6320. G.Fast requires 220 beside existing TLVs the following new TLVs. 222 5.1. Expected Throughput (ETR) TLV 224 Type: 0x009B Expected Throughput at L2 (ETR) upstream 226 Description: Reports the expected throughput upstream after 227 retransmission (ITU-T G.997.2, clause 7.11.1.2) 229 Length: 4 bytes 231 Value: Rate in kbits/s as a 32-bit unsigned integer 233 Type: 0x009C Expected Throughput at L2 (ETR) downstream 235 Description: Reports the expected throughput downstream after 236 retransmission (ITU-T G.997.2, clause 7.11.1.2) 237 Length: 4 bytes 239 Value: Rate in kbits/s as a 32-bit unsigned integer 241 5.2. Attainable expected throughput (ATTETR) TLV 243 Type: 0x009D Attainable Expected Throughput (ATTETR) upstream 245 Description: Reports the attainable expected Throughput upstream at 246 L2 (ITU-T G.997.2, clause 7.11.2.2) 248 Length: 4 bytes 250 Value: Rate in kbits/s as a 32-bit unsigned integer 252 Type: 0x009E Attainable Expected Throughput (ATTETR) downstream 254 Description: Reports the attainable expected Throughput downstream at 255 L2 (ITU-T G.997.2, clause 7.11.2.2) 257 Length: 4 bytes 259 Value: Rate in kbits/s as a 32-bit unsigned integer 261 5.3. Gamma Data Rate (GDR) TLV 263 Type: 0x009F Gamma data rate (GDR) upstream 265 Description: Reports the Gamma data rate (GDR) upstream (ITU-T 266 G.997.2, clause 7.11.1.3) 268 Length: 4 bytes 270 Value: Rate in kbits/s as a 32-bit unsigned integer 272 Type: 0x00A0 Gamma Data Rate (GDR) downstream 274 Description: Reports the Gamma data rate (GDR) downstream(ITU-T 275 G.997.2, clause 7.11.1.3) 277 Length: 4 bytes 279 Value: Rate in kbits/s as a 32-bit unsigned integer 281 5.4. Attainable Gamma Data Rate (ATTGDR) TLV 283 Type: 0x00A1 Attainable Gamma data rate (ATTGDR) upstream 284 Description: Reports the Attainable Gamma data rate upstream (ATTGDR) 285 (ITU-T G.997.2, clause 7.11.2.3) 287 Length: 4 bytes 289 Value: Rate in kbits/s as a 32-bit unsigned integer 291 Type: 0x00A2 Attainable Gamma data rate (ATTGDR) downstream 293 Description: Reports the Attainable Gamma data rate (ATTGDR) (ITU-T 294 G.997.2, clause 7.11.2.3) downstream 296 Length: 4 bytes 298 Value: Rate in kbits/s as a 32-bit unsigned integer 300 6. ANCP-Based PON Topology Discovery 302 This section describes topology discovery messages applied for PON. 303 TLVs not addressed here remain the same as applied for DSL. 305 6.1. ANCP Port Up and Port Down Event Message Descriptions 307 The format of the ANCP Port Up and Port Down Event messages is shown 308 in Figure xx1. It has the same format as the one described in 309 section 6.3 of RFC6320. The only difference is that DSL-Line- 310 Attributes TLV is updated as Access-Line-Attributes TLV. 312 0 1 2 3 313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | TCP/IP Encapsulating Header (Section 3.2) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | ANCP General Message Header | 318 + (Section 3.6.1) + 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 ~ Unused (20 bytes) ~ 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | # of TLVs | Extension Block length (bytes)| 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 ~ Access line identifying TLV(s) ~ 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | ACCESS-Line-Attributes TLV | 334 ~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~ 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 1: Format of the ANCP Port Up and Port Down Event Messages 339 for PON Topology Discovery 341 NOTE: TLVs MAY be in a different order from what is shown in this 342 figure. 344 Figure xx1: Format of the ANCP Port Up and Port Down Event Messages 345 for PON Topology Discovery 347 See Section 3.6.1 of RFC6320 for a description of the ANCP general 348 message header. The Message Type field MUST be set to 80 for Port 349 Up, 81 for Port Down. It is applicable to both DSL and PON based 350 access systems. The 4-bit Result field MUST be set to zero 351 (signifying Ignore). The 12-bit Result Code field and the 24-bit 352 Transaction Identifier field MUST also be set to zeroes. Other 353 fields in the general header MUST be set a as described in 354 Section 3.6 of RFC6320. 356 The five-word Unused field is a historical leftover. The handling of 357 unused/reserved fields is described in Section 3.4 of RFC6320. 359 The remaining message fields belong to the "extension block", and are 360 described as follows: 362 Extension Flags (8 bits): The flag bits denoted by 'x' are currently 363 unspecified and reserved. 365 Message Type (8 bits): Message Type has the same value as in the 366 general header (i.e., 80 or 81). 368 Tech Type (8 bits): MUST be set to 0x01 (PON). 370 Reserved (8 bits): set as described in Section 3.4 of RFC6320. 372 # of TLVs (16 bits): The number of TLVs that follow, not counting 373 TLVs encapsulated within other TLVs. 375 Extension Block Length (16 bits): The total length of the TLVs 376 carried in the extension block in bytes, including any padding within 377 individual TLVs. 379 TLVs: One or more TLVs to identify a PON Access line and zero or more 380 TLVs to define its characteristics. 382 6.2. PON Access Line Identification 384 Most ANCP messages involve actions relating to a specific access 385 line. Thus, it is necessary to describe how PON access lines are 386 identified within those messages. This section defines four TLVs for 387 that purpose and provides an informative description of how they are 388 used in PON. TLVs not addressed here remain unchanged as applied for 389 DSL. 391 6.2.1. Access-Loop-Circuit-ID TLV 393 Type: 0x0001 395 Description: A locally administered human-readable string generated 396 by or configured on the Access Node, uniquely identifying the 397 corresponding access loop logical port on the user side of the Access 398 Node, as described in Section 5.7 of [TR-156].. 400 Length: Up to 63 bytes 402 Value: ASCII string 404 6.2.2. Access-Loop-Remote-ID TLV 406 Type: 0x0002 408 Description: An operator-configured string that uniquely identifies 409 the user on the associated access line, as described in Section 5.7 410 of [TR-156]. 412 Length: Up to 63 bytes 414 Value: ASCII string 416 6.3. TLVs for PON Access Line Attributes 418 6.3.1. PON-Access-Line-Attributes TLV 420 Type: 0x0012 422 Description: This TLV encapsulates attribute values of a PON access 423 line serving a subscriber. 425 Length: Variable (up to 1023 bytes) 427 Value: One or more encapsulated TLVs corresponding to PON access line 428 attributes. The PON-Access-Line-Attributes TLV MUST contain at least 429 one TLV when it is present in a Port Up or Port Down message. The 430 actual contents are determined by the AN control application. 431 Technology-independent attributes of RFC6320, such as TLV0x0090, are 432 valid for PON and not repeated here. 434 6.3.2. PON-Access-Type TLV 436 Type: 0x0097 438 Description: Indicates the type of PON transmission system in use. 440 Length: 4 bytes 442 Value: 32-bit unsigned integer 444 OTHER = 0 446 GPON = 1 448 XG-PON1 = 2 449 TWDM-PON = 3 451 XGS-PON = 4 453 WDM-PON = 5 455 Unknown = 7 457 6.3.3. ONT/ONU-Average-Data-Rate-Downstream TLV 459 Type: 0x00b0 461 Description: ONT/ONU downstream average data rate L2 463 Length: 4 bytes 465 Value: Rate in kbits/s as a 32-bit unsigned integer 467 6.3.4. ONT/ONU-Peak-Data-Rate-Downstream TLV 469 Type: 0x00b1 471 Description: ONT/ONU downstream peak data rate L2 473 Length: 4 bytes 475 Value: Rate in kbits/s as a 32-bit unsigned integer 477 6.3.5. ONT/ONU-Maximum-Data-Rate-Upstream TLV 479 Type: 0x00b2 481 Description: ONT/ONU upstream maximum data rate L2 483 Length: 4 bytes 485 Value: Rate in kbits/s as a 32-bit unsigned integer 487 6.3.6. ONT/ONU-Assured-Data-Rate-Upstream TLV 489 Type: 0x00b3 491 Description: ONT/ONU upstream assured data rate L2 493 Length: 4 bytes 495 Value: Rate in kbits/s as a 32-bit unsigned integer 497 6.3.7. PON-Tree-Maximum-Data-Rate-Upstream TLV 499 Type: 0x00b4 501 Description: PON Tree upstream maximum data rate L2 503 Length: 4 bytes 505 Value: Rate in kbits/s as a 32-bit unsigned integer 507 6.3.8. PON-Tree-Maximum-Data-Rate-Downstream TLV 509 Type: 0x00b5 511 Description: PON Tree downstream maximum data rate L2 513 Length: 4 bytes 515 Value: Rate in kbits/s as a 32-bit unsigned integer 517 6.3.9. Reserved TLV 519 Type: 0x00b6 521 Description: Reserved 523 Length: tbd 525 Value: tbd 527 6.3.10. Reserved TLV 529 Type: 0x00b7 531 Description: Reserved 533 Length: tbd 535 Value: tbd 537 7. IANA Actions 539 7.1. ANCP TLV Type Registry 541 This document defines following sets of TLVs for PON, some of them 542 have defined by RFC6320 and are referenced here for completeness: 544 +----------+--------------------------------------------+-----------+ 545 | Type Code| TLV Name | Reference | 546 +----------+--------------------------------------------+-----------+ 547 | 0x0000 | Reserved | RFC 6320 | 548 | 0x0001 | Access-Loop-Circuit-ID | RFC 6320 | 549 | 0x0002 | Access-Loop-Remote-ID | RFC 6320 | 550 | 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFC 6320 | 551 | 0x0005 | Service-Profile-Name | RFC 6320 | 552 | 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFC 6320 | 553 | 0x0011 | Command | RFC 6320 | 554 | 0x0012 | PON-Access-Line-Attributes | RFC xxxx | 555 | 0x0097 | PON-Access-Type | RFC xxxx | 556 | 0x0098 | Reserved | RFC xxxx | 557 | 0x0099 | Reserved | RFC xxxx | 558 | 0x009A | Reserved | RFC xxxx | 559 | 0x009B | Expected Throughput (ETR) upnstream | RFC xxxx | 560 | 0x009C | Expected Throughput (ETR)-downstream | RFC xxxx | 561 | 0x009D | Attainable Expected Throughput (ATTETR) upstream | RFC xxxx | 562 | 0x009E | Attainable Expected Throughput (ATTETR)-downstream | RFC xxxx | 563 | 0x009F | Guaranteed Data Rate (GDR)-upnstream | RFC xxxx | 564 | 0x00A0 | Guaranteed Data Rate (GDR) downstream | RFC xxxx | 565 | 0x00A1 | Attainable Guaranteed Data Rate (ATTGDR)-upstream | RFC xxxx | 566 | 0x00A2 | Attainable Guaranteed Data Rate (ATTGDR)-downstream | RFC xxxx | 567 | 0x00B0 | ONT/ONU-Average-Data-Rate-Downstream | RFC xxxx | 568 | 0x00B1 | ONT/ONU-Peak-Data-Rate-Downstream | RFC xxxx | 569 | 0x00B2 | ONT/ONU-Maximum-Data-Rate-Upstream | RFC xxxx | 570 | 0x00B3 | ONT/ONU-Assured-Data-Rate-Upstream | RFC xxxx | 571 | 0x00B4 | PON-Tree-Maximum-Data-Rate-Upstream | RFC xxxx | 572 | 0x00B5 | PON-Tree-Maximum-Data-Rate-Downstream | RFC xxxx | 573 | 0x00B6 | Reserved | RFC xxxx | 574 | 0x00B7 | Reserved | RFC xxxx | 575 | 0x0106 | Status-Info | RFC 6320 | 576 | 0x1000 | Target (single access line variant) | RFC 6320 | 577 | 0x1001 - | Reserved for Target variants | RFC 6320 | 578 +----------+--------------------------------------------+-----------+ 580 8. Security Considerations 582 There are no new security considerations beyond what is described in 583 RFC6320 and RFC6934. 585 9. Acknowledgements 587 Many thanks to Norbert Voigt, John Gibbons, Sven Ooghe, Koen De 588 Sagher and Sven Leimer for joint work reviewing the document and 589 providing valuable comments to this document. 591 10. References 592 10.1. Normative References 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, 597 . 599 [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. 600 Taylor, Ed., "Protocol for Access Node Control Mechanism 601 in Broadband Networks", RFC 6320, DOI 10.17487/RFC6320, 602 October 2011, . 604 [RFC6934] Bitar, N., Ed., Wadhwa, S., Ed., Haag, T., and H. Li, 605 "Applicability of the Access Node Control Mechanism to 606 Broadband Networks Based on Passive Optical Networks 607 (PONs)", RFC 6934, DOI 10.17487/RFC6934, June 2013, 608 . 610 10.2. Informative References 612 [RFC5515] Mammoliti, V., Pignataro, C., Arberg, P., Gibbons, J., and 613 P. Howard, "Layer 2 Tunneling Protocol (L2TP) Access Line 614 Information Attribute Value Pair (AVP) Extensions", 615 RFC 5515, DOI 10.17487/RFC5515, May 2009, 616 . 618 [TR-156_Issue-3] 619 Forum, T. B., "Using GPON Access in the context of TR- 620 101", November 2012. 622 Authors' Addresses 624 Hongyu Li 625 Huawei Technologies Co., Ltd. 626 Industrial Base, bantain Longgang 627 Shenzhen 628 518129 629 P.R. China 630 Email: honyu.li@huawei.com 632 Thomas Haag 633 Deutsche Telekom 634 Heinrich-Hertz_Strasse 3-7 635 64295 Darmstadt 636 Germany 637 Email: haagt@telekom.de 638 Birgit Witschurke 639 Deutsche Telekom 640 Winterfeldstrasse 21 641 10781 Berlin 642 Germany 643 Email: b.witschurke@telekom.de