idnits 2.17.1 draft-lihawi-ancp-protocol-access-extension-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 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 28 instances of too long lines in the document, the longest one being 47 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 (August 17, 2018) is 2077 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 117, but not defined == Missing Reference: 'TR-156' is mentioned on line 419, but not defined == Unused Reference: 'RFC5515' is defined on line 619, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 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: February 18, 2019 B. Witschurke 6 Deutsche Telekom 7 August 17, 2018 9 Access Extensions for the Access Node Control Protocol 10 draft-lihawi-ancp-protocol-access-extension-00 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 February 18, 2019. 46 Copyright Notice 48 Copyright (c) 2018 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 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. 3. Modification to ANCP - General Aspects . . . . . . . . . . 4 66 4. Modification to DSL-Type TLV 0x0091 . . . . . . . . . . . . . 5 67 5. Extension to DSL Sub TLV . . . . . . . . . . . . . . . . . . 5 68 5.1. Expected Throughput (ETR) TLV . . . . . . . . . . . . . . 5 69 5.2. Attainable Expected Throughput (ATTETR) . . . . . . . . . 6 70 5.3. Attainable Expected Throughput at L2 . . . . . . . . . . 6 71 5.4. Gamma data rate (GDR) upstream . . . . . . . . . . . . . 6 72 5.5. Gamma data rate (GDR) downstream . . . . . . . . . . . . 6 73 5.6. Attainable Gamma data rate (ATTGDR) upstream . . . . . . 7 74 5.7. Attainable Gamma data rate (ATTGDR) downstream . . . . . 7 75 6. ANCP-Based PON Topology Discovery . . . . . . . . . . . . . . 7 76 6.1. ANCP Port Up and Port Down Event Message Descriptions . . 7 77 6.2. PON Access Line Identification . . . . . . . . . . . . . 9 78 6.2.1. Access-Loop-Circuit-ID TLV . . . . . . . . . . . . . 9 79 6.2.2. Access-Loop-Remote-ID TLV . . . . . . . . . . . . . . 10 80 6.3. TLVs for PON Access Line Attributes . . . . . . . . . . . 10 81 6.3.1. PON-Access-Line-Attributes TLV . . . . . . . . . . . 10 82 6.3.2. PON-Access-Type TLV . . . . . . . . . . . . . . . . . 10 83 6.3.3. ONT/ONU-Average-Data-Rate-Downstream TLV . . . . . . 11 84 6.3.4. ONT/ONU-Peak-Data-Rate-Downstream TLV . . . . . . . . 11 85 6.3.5. ONT/ONU-Maximum-Data-Rate-Upstream TLV . . . . . . . 11 86 6.3.6. ONT/ONU-Assured-Data-Rate-Upstream TLV . . . . . . . 11 87 6.3.7. PON-Tree-Maximum-Data-Rate-Upstream TLV . . . . . . . 12 88 6.3.8. PON-Tree-Maximum-Data-Rate-Downstream TLV . . . . . . 12 89 6.3.9. Reserved TLV . . . . . . . . . . . . . . . . . . . . 12 90 6.3.10. Reserved TLV . . . . . . . . . . . . . . . . . . . . 12 91 7. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.1. ANCP TLV Type Registry . . . . . . . . . . . . . . . . . 12 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 97 10.2. Informative References . . . . . . . . . . . . . . . . . 14 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 RFC6934 introduces application of ANCP to PON. However, RFC6320 103 [RFC6320] haven't been updated to support PON. Besides, DSL 104 technology is also evolving. G.fast, VDSL2 Vectoring and VDSL2 Annex 105 Q were introduced as upgraded versions to provide higher bandwidths 106 for the last mile.. 108 This document considers all existing Access technologies used in a 109 Telco network, yet not supported by RFC6320 and specifies new TLVs 110 accordingly. 112 2. Terminology 114 This section repeats some definitions from RFC6320 and RFC6934 115 [RFC6934], but also updates some definitions where appropriate. 117 Access Node (AN): [RFC5851] Network device, usually located at a 118 service provider central office or street cabinet that terminates 119 access (local) loop connections from subscribers. In case the access 120 loop is a Digital Subscriber Line (DSL), the Access Node provides DSL 121 signal termination and is referred to as a DSL Access Multiplexer 122 (DSLAM). In case the access loop is a Passive Optical Network (PON), 123 the Access Node is referred to as an Optical Line Terminal (OLT). 125 Optical Line Terminal (OLT): is located in the service provider's 126 central office (CO) or street cabinet. It terminates and aggregates 127 multiple PONs (providing fiber access to multiple premises or 128 neighborhoods) on the subscriber side and interfaces with the Network 129 Access Server (NAS) that provides subscriber management. 131 Optical Network Terminal (ONT): terminates PON on the network side 132 and provides PON adaptation. The subscriber side interface and the 133 location of the ONT are dictated by the type of network deployment. 134 For an FTTP deployment (with fiber all the way to the apartment or 135 living unit), ONT has Ethernet (Fast Ethernet (FE) / Gigabit Ethernet 136 (GE) / Multimedia over Coax Alliance (MoCA)) connectivity with the 137 Home Gateway (HGW) / Customer Premises Equipment (CPE). In certain 138 cases, one ONT may provide connections to more than one Home Gateway 139 at the same time. 141 Optical Network Unit (ONU): a generic term denoting a device that 142 terminates any one of the distributed (leaf) endpoints of an Optical 143 Distribution Network (ODN), implements a PON protocol, and adapts PON 144 PDUs to subscriber service interfaces. In the case of a multi- 145 dwelling unit (MDU) or multi-tenant unit (MTU), a multi-subscriber 146 ONU typically resides in the basement or a wiring closet (FTTB case) 147 and has FE/GE/Ethernet over native Ethernet link or over xDSL 148 (typically VDSL2) connectivity with each CPE at the subscriber 149 premises. In the case where fiber is terminated outside the premises 150 (neighborhood or curb side) on an ONT/ONU, the last-leg-premises 151 connections could be via existing or new copper, with xDSL physical 152 layer (typically VDSL2). In this case, the ONU effectively is a 153 "PON-fed DSLAM". In new FTTdp based deployments the access node is 154 named DPU (Distribution Point Unit). Basically from ANCP perspective 155 this node provides the same functionality. 157 3. 3. Modification to ANCP - General Aspects 159 ANCP message formats remain the same as described in section 3.5.1 of 160 RFC6320 when it's applied to PON. However, some message descriptions 161 need to be modified to make them applicable to variant Access 162 Networks, other than DSL specific. 164 The ANCP Adjacency message is extended to other Access Technologies 165 than DSL. Generalize the message format to following: 167 The following capabilities are defined for ANCP: 169 o Capability Type: Access Topology Discovery = 0x01 171 Access technology: ANY 173 Length (in bytes): 0 175 Capability Data: NULL 177 For the detailed protocol specification of this capability, see 178 Section 6 of RFC6320. 180 o Capability Type: Access Line Configuration = 0x02 182 Access technology: ANY 184 Length (in bytes): 0 186 Capability Data: NULL 188 For the detailed protocol specification of this capability, see 189 Section 7 of RFC6320. 191 o Capability Type: Access Remote Line Connectivity Testing = 0x04 193 Access technology: ANY 195 Length (in bytes): 0 197 Capability Data: NULL 199 For the detailed protocol specification of this capability, see 200 Section 8 of RFC6320. 202 4. Modification to DSL-Type TLV 0x0091 204 Add following new DSL-Type values. 206 Value: 32-bit unsigned integer 208 G.fast = 8 210 VDSL2 Annex Q = 9 212 SDSL bonded = 10 214 VDSL2 bonded = 11 216 G.fast bonded = 12 218 VDSL2 Annex Q bonded = 13 220 5. Extension to DSL Sub TLV 222 DSL sub TLVs are listed in Section 6.5 of RFC6320. G.Fast requires 223 beside existing TLVs the following new TLVs. 225 5.1. Expected Throughput (ETR) TLV 227 Type: 0x009B Expected Throughput at L2 (ETR) upstream 229 Description: Reports the expected throughput downstream after 230 retransmission (ITU-T G.997.2, clause 7.11.1.2) 232 Length: 4 bytes 234 Value: Rate in kbits/s as a 32-bit unsigned integer 235 Type: 0x009C Expected Throughput at L2 (ETR) downstream 237 Description: Reports the expected throughput upstream after 238 retransmission (ITU-T G.997.2, clause 7.11.1.2) 240 Length: 4 bytes 242 Value: Rate in kbits/s as a 32-bit unsigned integer 244 5.2. Attainable Expected Throughput (ATTETR) 246 Type: 0x009D 248 Description: Reports the attainable expected Throughput at L2 (ITU-T 249 G.997.2, clause 7.11.2.2) upstream 251 Length: 4 bytes 253 Value: Rate in kbits/s as a 32-bit unsigned integer 255 5.3. Attainable Expected Throughput at L2 257 Type: 0x009E 259 Description: Reports the attainable expected Throughput at L2 (ITU-T 260 G.997.2, clause 7.11.2.2) downstream 262 Length: 4 bytes 264 Value: Rate in kbits/s as a 32-bit unsigned integer 266 5.4. Gamma data rate (GDR) upstream 268 Type: 0x009F 270 Description: Reports the Gamma data rate (GDR) (ITU-T G.997.2, clause 271 7.11.1.3) upstream 273 Length: 4 bytes 275 Value: Rate in kbits/s as a 32-bit unsigned integer 277 5.5. Gamma data rate (GDR) downstream 279 Type: 0x00A0 281 Description: Reports the Gamma data rate (GDR) (ITU-T G.997.2, clause 282 7.11.1.3) downstream 283 Length: 4 bytes 285 Value: Rate in kbits/s as a 32-bit unsigned integer 287 5.6. Attainable Gamma data rate (ATTGDR) upstream 289 Type: 0x00A1 291 Description: Reports the Attainable Gamma data rate (ATTGDR) (ITU-T 292 G.997.2, clause 7.11.2.3) upstream 294 Length: 4 bytes 296 Value: Rate in kbits/s as a 32-bit unsigned integer 298 5.7. Attainable Gamma data rate (ATTGDR) downstream 300 Type: 0x00A2 302 Description: Reports the Attainable Gamma data rate (ATTGDR) (ITU-T 303 G.997.2, clause 7.11.2.3) downstream 305 Length: 4 bytes 307 Value: Rate in kbits/s as a 32-bit unsigned integer 309 6. ANCP-Based PON Topology Discovery 311 This section describes topology discovery messages applied for PON. 312 TLVs not addressed here remain the same as applied for DSL. 314 6.1. ANCP Port Up and Port Down Event Message Descriptions 316 The format of the ANCP Port Up and Port Down Event messages is shown 317 in Figure xx1. It has the same format as the one described in 318 section 6.3 of RFC6320. The only difference is that DSL-Line- 319 Attributes TLV is updated as Access-Line-Attributes TLV. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | TCP/IP Encapsulating Header (Section 3.2) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | ANCP General Message Header | 327 + (Section 3.6.1) + 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 ~ Unused (20 bytes) ~ 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | # of TLVs | Extension Block length (bytes)| 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 ~ Access line identifying TLV(s) ~ 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | ACCESS-Line-Attributes TLV | 343 ~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~ 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Format of the ANCP Port Up and Port Down Event Messages for PON 348 Topology Discovery 350 NOTE: TLVs MAY be in a different order from what is shown in this 351 figure. 353 Figure xx1: Format of the ANCP Port Up and Port Down Event Messages 354 for PON Topology Discovery 356 See Section 3.6.1 of RFC6320 for a description of the ANCP general 357 message header. The Message Type field MUST be set to 80 for Port 358 Up, 81 for Port Down. It is applicable to both DSL and PON based 359 access systems. The 4-bit Result field MUST be set to zero 360 (signifying Ignore). The 12-bit Result Code field and the 24-bit 361 Transaction Identifier field MUST also be set to zeroes. Other 362 fields in the general header MUST be set a as described in 363 Section 3.6 of RFC6320. 365 The five-word Unused field is a historical leftover. The handling of 366 unused/reserved fields is described in Section 3.4 of RFC6320. 368 The remaining message fields belong to the "extension block", and are 369 described as follows: 371 Extension Flags (8 bits): The flag bits denoted by 'x' are currently 372 unspecified and reserved. 374 Message Type (8 bits): Message Type has the same value as in the 375 general header (i.e., 80 or 81). 377 Tech Type (8 bits): MUST be set to 0x01 (PON). 379 Reserved (8 bits): set as described in Section 3.4 of RFC6320. 381 # of TLVs (16 bits): The number of TLVs that follow, not counting 382 TLVs encapsulated within other TLVs. 384 Extension Block Length (16 bits): The total length of the TLVs 385 carried in the extension block in bytes, including any padding within 386 individual TLVs. 388 TLVs: One or more TLVs to identify a PON Access line and zero or more 389 TLVs to define its characteristics. 391 6.2. PON Access Line Identification 393 Most ANCP messages involve actions relating to a specific access 394 line. Thus, it is necessary to describe how PON access lines are 395 identified within those messages. This section defines four TLVs for 396 that purpose and provides an informative description of how they are 397 used in PON. TLVs not addressed her are remain unchanged applied for 398 DSL. 400 6.2.1. Access-Loop-Circuit-ID TLV 402 Type: 0x0001 404 Description: A locally administered human-readable string generated 405 by or configured on the Access Node, uniquely identifying the 406 corresponding access loop logical port on the user side of the Access 407 Node, as described in Section 5.7 of [TR-156].. 409 Length: Up to 63 bytes 411 Value: ASCII string 413 6.2.2. Access-Loop-Remote-ID TLV 415 Type: 0x0002 417 Description: An operator-configured string that uniquely identifies 418 the user on the associated access line, as described in Section 5.7 419 of [TR-156]. 421 Length: Up to 63 bytes 423 Value: ASCII string 425 6.3. TLVs for PON Access Line Attributes 427 6.3.1. PON-Access-Line-Attributes TLV 429 Type: 0x0012 431 Description: This TLV encapsulates attribute values of a PON access 432 line serving a subscriber. 434 Length: Variable (up to 1023 bytes) 436 Value: One or more encapsulated TLVs corresponding to PON access line 437 attributes. The PON-Access-Line-Attributes TLV MUST contain at least 438 one TLV when it is present in a Port Up or Port Down message. The 439 actual contents are determined by the AN control application. Non 440 PON specific attributes of RFC6320 such as TLV0x0090 are valid for 441 PON and not repeated here.. 443 6.3.2. PON-Access-Type TLV 445 Type: 0x0092 447 Description: Indicates the type of PON transmission system in use. 449 Length: 4 bytes 451 Value: 32-bit unsigned integer 453 OTHER = 0 455 GPON = 1 457 XG-PON1 = 2 459 TWDM-PON = 3 460 XGS-PON = 4 462 WDM-PON = 5 464 Unknown = 7 466 6.3.3. ONT/ONU-Average-Data-Rate-Downstream TLV 468 Type: 0x0093 470 Description: ONT/ONU downstream average data rate L2 472 Length: 4 bytes 474 Value: Rate in kbits/s as a 32-bit unsigned integer 476 6.3.4. ONT/ONU-Peak-Data-Rate-Downstream TLV 478 Type: 0x0094 480 Description: ONT/ONU downstream peak data rate L2 482 Length: 4 bytes 484 Value: Rate in kbits/s as a 32-bit unsigned integer 486 6.3.5. ONT/ONU-Maximum-Data-Rate-Upstream TLV 488 Type: 0x0095 490 Description: ONT/ONU upstream maximum data rate L2 492 Length: 4 bytes 494 Value: Rate in kbits/s as a 32-bit unsigned integer 496 6.3.6. ONT/ONU-Assured-Data-Rate-Upstream TLV 498 Type: 0x0096 500 Description: ONT/ONU upstream assured data rate L2 502 Length: 4 bytes 504 Value: Rate in kbits/s as a 32-bit unsigned integer 506 6.3.7. PON-Tree-Maximum-Data-Rate-Upstream TLV 508 Type: 0x0097 510 Description: PON Tree upstream maximum data rate L2 512 Length: 4 bytes 514 Value: Rate in kbits/s as a 32-bit unsigned integer 516 6.3.8. PON-Tree-Maximum-Data-Rate-Downstream TLV 518 Type: 0x0098 520 Description: PON Tree downstream maximum data rate L2 522 Length: 4 bytes 524 Value: Rate in kbits/s as a 32-bit unsigned integer 526 6.3.9. Reserved TLV 528 Type: 0x0099 530 Description: Reserved 532 Length: 4 bytes 534 Value: Rate in kbits/s as a 32-bit unsigned integer 536 6.3.10. Reserved TLV 538 Type: 0x009A 540 Description: Reserved 542 Length: 4 bytes 544 Value: Rate in kbits/s as a 32-bit unsigned integer 546 7. IANA Actions 548 7.1. ANCP TLV Type Registry 550 This document defines following sets of TLVs for PON, some of them 551 have defined by RFC6320 and are referenced here for completeness: 553 +----------+--------------------------------------------+-----------+ 554 | Type Code| TLV Name | Reference | 555 +----------+--------------------------------------------+-----------+ 556 | 0x0000 | Reserved | RFC 6320 | 557 | 0x0001 | Access-Loop-Circuit-ID | RFC 6320 | 558 | 0x0002 | Access-Loop-Remote-ID | RFC 6320 | 559 | 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFC 6320 | 560 | 0x0005 | Service-Profile-Name | RFC 6320 | 561 | 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFC 6320 | 562 | 0x0011 | Command | RFC 6320 | 563 | 0x0012 | PON-Access-Line-Attributes | RFC xxxx | 564 | 0x0092 | PON-Access-Type | RFC xxxx | 565 | 0x0093 | ONT/ONU-Average-Data-Rate-Downstream | RFC xxxx | 566 | 0x0094 | ONT/ONU-Peak-Data-Rate-Downstream | RFC xxxx | 567 | 0x0095 | ONT/ONU-Maximum-Data-Rate-Upstream | RFC xxxx | 568 | 0x0096 | ONT/ONU-Assured-Data-Rate-Upstream | RFC xxxx | 569 | 0x0097 | PON-Tree-Maximum-Data-Rate-Upstream | RFC xxxx | 570 | 0x0098 | PON-Tree-Maximum-Data-Rate-Downstream | RFC xxxx | 571 | 0x0099 | Reserved | RFC xxxx | 572 | 0x009A | Reserved | RFC xxxx | 573 | 0x009B | Expected Throughput (ETR) upnstream | RFC xxxx | 574 | 0x009C | Expected Throughput (ETR)-downstream | RFC xxxx | 575 | 0x009D | Attainable Expected Throughput (ATTETR) upstream | RFC xxxx | 576 | 0x009E | Attainable Expected Throughput (ATTETR)-downstream | RFC xxxx | 577 | 0x009F | Guaranteed Data Rate (GDR)-upnstream | RFC xxxx | 578 | 0x00A0 | Guaranteed Data Rate (GDR) downstream | RFC xxxx | 579 | 0x00A1 | Attainable Guaranteed Data Rate (ATTGDR)-upstream | RFC xxxx | 580 | 0x00A2 | Attainable Guaranteed Data Rate (ATTGDR)-downstream | RFC xxxx | 581 | 0x0106 | Status-Info | RFC 6320 | 582 | 0x1000 | Target (single access line variant) | RFC 6320 | 583 | 0x1001 - | Reserved for Target variants | RFC 6320 | 584 +----------+--------------------------------------------+-----------+ 586 8. Security Considerations 588 There are no new security considerations beyond what is described in 589 RFC6320 and RFC6934. 591 9. Acknowledgements 593 Many thanks to Norbert Voigt, John Gibbons, Sven Ooghe, Koen De 594 Sagher and Sven Leimer for joint work reviewing the document and 595 providing valuable comments to this document. 597 10. References 599 10.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, 603 DOI 10.17487/RFC2119, March 1997, 604 . 606 [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. 607 Taylor, Ed., "Protocol for Access Node Control Mechanism 608 in Broadband Networks", RFC 6320, DOI 10.17487/RFC6320, 609 October 2011, . 611 [RFC6934] Bitar, N., Ed., Wadhwa, S., Ed., Haag, T., and H. Li, 612 "Applicability of the Access Node Control Mechanism to 613 Broadband Networks Based on Passive Optical Networks 614 (PONs)", RFC 6934, DOI 10.17487/RFC6934, June 2013, 615 . 617 10.2. Informative References 619 [RFC5515] Mammoliti, V., Pignataro, C., Arberg, P., Gibbons, J., and 620 P. Howard, "Layer 2 Tunneling Protocol (L2TP) Access Line 621 Information Attribute Value Pair (AVP) Extensions", 622 RFC 5515, DOI 10.17487/RFC5515, May 2009, 623 . 625 [TR-156_Issue-3] 626 The Broadband Forum, "Using GPON Access in the context of 627 TR-101", November 2012. 629 Authors' Addresses 631 Hongyu Li 632 Huawei Technologies Co., Ltd. 633 Industrial Base, bantain Longgang 634 Shenzhen 518129 635 P.R. China 637 Email: lihy@huawei.com 638 Thomas Haag 639 Deutsche Telekom 640 Heinrich-Hertz_Strasse 3-7 641 Darmstadt 64295 642 Germany 644 Email: haagt@telekom.de 646 Birgit Witschurke 647 Deutsche Telekom 648 Winterfeldstrasse 21 649 Berlin 10781 650 Germany 652 Email: b.witschurke@telekom.de