idnits 2.17.1 draft-ietf-ancp-pon-05.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 : ---------------------------------------------------------------------------- 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 date (February 25, 2013) is 4040 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: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Nabil Bitar(ed.) 3 Verizon 4 Internet Draft 5 Intended Status: Informational Sanjay Wadhwa (ed.) 6 Alcatel-Lucent 7 Expires: August 25, 2013 8 Thomas Haag 9 Deutsche Telekom 11 Hongyu Li 12 Huawei Technologies 14 February 25, 2013 16 Applicability of Access Node Control Mechanism to 17 PON based Broadband Networks 19 draft-ietf-ancp-pon-05.txt 21 Abstract 23 The purpose of this document is to provide applicability of the 24 Access Node Control mechanism to Passive Optical Network (PON)-based 25 broadband access. The need for an Access Node Control mechanism 26 between a Network Access Server (NAS) and an Access Node Complex (a 27 combination of Optical Line Termination (OLT) and Optical Network 28 Termination (ONT) elements) is described in a multi-service reference 29 architecture in order to perform QoS-related, service-related and 30 Subscriber-related operations. The Access Node Control mechanism is 31 also extended for interaction between components of the Access Node 32 Complex (OLT and ONT). The Access Node Control mechanism will ensure 33 that the transmission of information between the NAS and Access Node 34 Complex (ANX) and between the OLT and ONT within an ANX does not need 35 to go through distinct element managers but rather uses a direct 36 device-to-device communication and stays on net. This allows for 37 performing access link related operations within those network 38 elements to meet performance objectives. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute working 47 documents as Internet-Drafts. The list of current Internet-Drafts is 48 at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on August 25,2013. 57 Copyright Notice 59 Copyright (c) 2013 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with 67 respect to this document. Code Components extracted from this 68 document must include Simplified BSD License text as described in 69 Section 4.e of the Trust Legal Provisions and are provided without 70 warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction 75 ..................................................... 3 76 2. Terminology 77 ...................................................... 5 78 3. Motivation for explicit extension of ANCP to FTTx PON ............ 7 79 4. Reference Model for PON Based Broadband Access Network 80 ........... 8 81 4.1. Functional Blocks ............................................. 10 82 4.1.1. Home Gateway ............................................... 10 83 4.1.2. PON Access ................................................. 10 84 4.1.3. Access Node Complex ........................................ 11 85 4.1.4. Access Node Complex Uplink to the NAS ....................... 11 86 4.1.5. Aggregation Network ......................................... 11 87 4.1.6. Network Access Server ....................................... 11 88 4.1.7. Regional Network ............................................ 11 89 4.2. Access Node Complex Control Reference Architecture Options .... 12 90 4.2.1. ANCP+OMCI ANX Control ....................................... 12 91 4.2.2. All-ANCP ANX Control ........................................ 13 92 5. Concept of Access Node Control Mechanism for PON Based Access ... 14 93 6. Multicast ....................................................... 17 94 6.1. Multicast Conditional Access .................................. 18 95 6.2. Multicast Admission Control ................................... 20 96 6.3. Multicast Accounting .......................................... 33 97 7. Remote Connectivity Check ....................................... 33 98 8. Access Topology Discovery ....................................... 34 99 9. Access Loop Configuration ....................................... 36 100 10. Security Considerations ........................................ 37 101 11. Differences in ANCP applicability between DSL and PON .......... 38 102 12. ANCP versus OMCI between the OLT and ONT/ONU ................... 39 103 13. IANA Considerations 104 ............................................ 40 105 14. Acknowledgements ............................................... 40 106 15. References 107 ..................................................... 41 108 15.1. Normative References ........................................ 41 109 15.2. Informative References ....................................... 41 111 1. Introduction 113 Passive Optical Networks (PONs) based on BPON [G.983.1] and GPON 114 [G.984.1] are being deployed across carrier networks. There are two 115 models for PON deployment: Fiber to the building/curb (FTTB/FTTC), 116 and Fiber to the Premises (FTTP). In the FTTB/C deployment, the last 117 mile connectivity to the subscriber premises is provided over the 118 local Copper loop, often using Very High Speed Digital Subscriber 119 line (VDSL). In the FTTP case, PON extends to the premises of the 120 subscriber. In addition, there are four main PON technologies: (1) 121 Broadband PON (BPON), (2) Gigabit PON (GPON), (3) 10-Gigabit PON (XG- 122 PON), and (4) Ethernet PON (EPON). This document describes the 123 applicability of Access Node Control Protocol (ANCP) in the context 124 of FTTB/C and FTTP deployments, focusing on BPON, GPON and XG-PON. 125 Architectural considerations lead to different ANCP compositions. 126 Therefore, the composition of ANCP communication between Access Nodes 127 and Network Access Server (NAS) is described using different models. 129 BPON, GPON and XG-PON in FTTP deployments provide large bandwidth in 130 the first mile, bandwidth that is an order of magnitude larger than 131 that provided by xDSL. In the downstream direction, BPON 132 provides 622 Mbps per PON while GPON provides 2.4 Gbps, and XG-PON 133 provides 10 Gbps. 135 In residential deployments, the number of homes sharing the same PON 136 is limited by the technology and the network engineering rules. 137 Typical deployments have 32-64 homes per PON. 139 The motive behind BPON, GPON and XG-PON deployment is providing 140 triple-play services over IP: voice, video and data. Voice is 141 generally low bandwidth but has low-delay, low-jitter, and low 142 packet-loss requirements. Data services (e.g., Internet services) 143 often require high throughput and can tolerate medium latency. Data 144 services may include multimedia content download such as video. 145 However, in that case, the video content is not required to be real- 146 time and/or it is low quality video. Video services, on the other 147 hand, are targeted to deliver Standard Definition or High Definition 148 video content in real-time or near-real time, depending on the 149 service model. Standard Definition content using MPEG2 encoding 150 requires on the order of 3.75 Mbps per stream while High definition 151 content using MPEG2 encoding requires on the order of 15-19 Mbps 152 depending on the level of compression used. Video services require 153 low-jitter and low-packet loss with low start-time latency. There are 154 two types of video services: on demand and broadcast (known also as 155 liner programming content). While linear programming content can be 156 provided over Layer1 on the PON, the focus in this document is on 157 delivering linear programming content over IP to the subscriber, 158 using IP multicast. Video on demand is also considered for delivery 159 to the subscriber over IP using a unicast session model. 161 Providing simultaneous triple-play services over IP with unicast 162 video and multicast video, VoIP and data requires an architecture 163 that preserves the quality of service of each service. Fundamental to 164 this architecture is ensuring that the video content (unicast and 165 multicast) delivered to the subscriber does not exceed the bandwidth 166 allocated to the subscriber for video services. Architecture models 167 often ensure that data is guaranteed a minimum bandwidth and that 168 VoIP is guaranteed its own bandwidth. In addition, QoS control across 169 services is often performed at a Network Access Server (NAS), often 170 referred to as Broadband Network Gateway (BNG) for subscriber 171 management, per subscriber and shared link resources. Efficient 172 multicast video services require enabling multicast services in the 173 access network between the subscriber and the subscriber management 174 platform. In the FTTP/B/C PON environment, this implies enabling IP 175 multicast on the Access Node (AN) complex composed of the Optical 176 Network Terminal (ONT) or Unit (ONU) and Optical Line Terminal (OLT), 177 as applicable. This is as opposed to Digital Subscriber Line (DSL) 178 deployments where multicast is enabled on the DSL Access Multiplexer 179 (DSLAM) only. The focus in this document will be on the ANCP 180 requirements needed for coordinated admission control of unicast and 181 multicast video in FTTP/B/C PON environments between the AN complex 182 (ANX) and the NAS, specifically focusing on bandwidth dedicated for 183 multicast and shared bandwidth between multicast and unicast. 185 [RFC5851] provides the framework and requirements for coordinated 186 admission control between a NAS and an AN with special focus on DSL 187 deployments. This document extends that framework and the related 188 requirements to explicitly address PON deployments. 190 2. Terminology 192 - PON (Passive Optical Network) [G.983.1][G.984.1]: a point-to- 193 multipoint fiber to the premises network architecture in which 194 unpowered splitters are used to enable the splitting of an optical 195 signal from a central office on a single optical fiber to multiple 196 premises. Up to 32-128 may be supported on the same PON. A PON 197 configuration consists of an Optical Line Terminal (OLT) at the 198 Service Provider's Central Office (CO) and a number of Optical 199 Network Units or Terminals (ONU/ONT) near end users, with an optical 200 distribution network (ODN) composed of fibers and splitters between 201 them. A PON configuration reduces the amount of fiber and CO 202 equipment required compared with point-to-point architectures. 204 - Access Node Complex (ANX): The Access Node Complex is composed of 205 two geographically separated functional elements OLT and ONU/ONT. The 206 general term Access Node Complex (ANX) will be used when describing a 207 functionality which does not depend on the physical location but 208 rather on the "black box" behavior of OLT and ONU/ONT. 210 -Optical Line Terminal (OLT): is located in the Service provider's 211 central office (CO). It terminates and aggregates multiple PONs 212 (providing fiber access to multiple premises or neighborhoods) on the 213 subscriber side, and interfaces with the Network Access server (NAS) 214 that provides subscriber management. 216 - Optical Network Terminal (ONT): terminates PON on the network side 217 and provides PON adaptation. The subscriber side interface and the 218 location of the ONT are dictated by the type of network deployment. 219 For a Fiber-to-the-Premise (FTTP) deployment (with Fiber all the way 220 to the apartment or living unit), ONT has Ethernet (FE/GE/MoCA) 221 connectivity with the Home Gateway (HGW)/Customer Premise 222 Equipment(CPE). In certain cases, one ONT may provide connections to 223 more than one Home Gateway at the same time. 225 -Optical Network Unit (ONU): A generic term denoting a device that 226 terminates any one of the distributed (leaf) endpoints of an Optical 227 Distribution Node (ODN), implements a PON protocol, and adapts PON 228 PDUs to subscriber service interfaces. In case of an MDU multi- 229 dwelling or multi-tenant unit, a multi-subscriber ONU typically 230 resides in the basement or a wiring closet (FTTB case), and has 231 FE/GE/Ethernet over native Ethernet link or over xDSL (typically 232 VDSL) connectivity with each CPE at the subscriber premises. In the 233 case where fiber is terminated outside the premises (neighborhood or 234 curb side) on an ONT/ONU, the last-leg-premises connections could be 235 via existing or new Copper, with xDSL physical layer (typically 236 VDSL). In this case, the ONU effectively is a "PON fed DSLAM". 238 -Network Access Server (NAS): Network element which aggregates 239 subscriber traffic from a number of ANs or ANXs. The NAS is often an 240 injection point for policy management and IP QoS in the access 241 network. It is also referred to as Broadband Network Gateway (BNG) or 242 Broadband Remote Access Server (BRAS). 244 -Home Gateway (HGW): Network element that connects subscriber devices 245 to the AN or ANX and the access network. In case of xDSL, the Home 246 Gateway is an xDSL network termination that could either operate as a 247 Layer 2 bridge or as a Layer 3 router. In the latter case, such a 248 device is also referred to as a Routing Gateway (RG). In the case of 249 PON, it is often a Layer3 routing device with the ONT performing PON 250 termination. 252 -PON-Customer-ID: This is an identifier which uniquely identifies the 253 ANX and the access loop logical port on the ANX to the subscriber 254 (customer) premises, and is used in any interaction between NAS and 255 ANX that relates to access-loops. Logically it is composed of 256 information containing identification of the OLT (the OLT may be 257 physically directly connected to the NAS), the PON port on the OLT, 258 the ONT/ONU, and the port on the ONT/ONU connecting to the subscriber 259 HGW. When acting as a DHCP relay agent, the OLT can encode PON- 260 Customer-ID in the "Agent-Circuit-Identifier" Sub-option in Option-82 261 of the DHCP messages [RFC3046]. 263 3. Motivation for explicit extension of ANCP to FTTx PON 265 The fundamental difference between PON and DSL is that a PON is an 266 optical broadcast network by definition. That is, at the PON level, 267 every ONT on the same PON sees the same signal. However, the ONT 268 filters only those PON frames addressed to it. Encryption is used on 269 the PON to prevent eavesdropping. 271 The broadcast PON capability is very suitable to delivering multicast 272 content to connected premises, maximizing bandwidth usage efficiency 273 on the PON. Similar to DSL deployments, enabling multicast on the 274 Access Node Complex (ANX) provides for bandwidth use efficiency on 275 the path between the Access Node and the NAS as well as improves the 276 scalability of the NAS by reducing the amount of multicast traffic 277 being replicated at the NAS. However, the broadcast capability on the 278 PON enables the AN (OLT) to send one copy on the PON as opposed to 279 one copy to each receiver on the PON. The PON multicast capability 280 can be leveraged in the case of GPON and BPON as discussed in this 281 document. 283 Fundamental to leveraging the broadcast capability on the PON for 284 multicast delivery is the ability to assign a single encryption key 285 for all PON frames carrying all multicast channels or a key per set 286 of multicast channels that correspond to service packages, or none. 287 When supporting encryption for multicast channels, the encryption key 288 is generated by the OLT and sent by the OLT to each targeted ONT via 289 the ONT Management and Control Interface (OMCI) as described in 290 section 15.5.2 of ITU-T G.987.3 [G.987.3] for XG-PON. It should be 291 noted that the ONT can be a multi-Dwelling Unit (MDU) ONT with 292 multiple Ethernet ports, each connected to a living unit. Thus, the 293 ONT must not only be able to receive a multicast frame, but must also 294 be able to forward that frame only to the Ethernet port with 295 receivers for the corresponding channel. 297 In order to implement triple-play service delivery with necessary 298 "quality-of-experience", including end-to-end bandwidth optimized 299 multicast video delivery, there needs to be tight coordination 300 between the NAS and the ANX. This interaction needs to be near real- 301 time as services are requested via application or network level 302 signaling by broadband subscribers. ANCP as defined in [RFC5851] for 303 DSL based networks is very suitable to realize a control protocol 304 (with transactional exchange capabilities), between PON enabled ANX 305 and the NAS, and also between the components comprising the ANX, 306 i.e., between OLT and the ONT. Typical use cases for ANCP in PON 307 environment include the following: 309 - Access topology discovery 310 - Access Loop Configuration 311 - Multicast 312 - Optimized multicast delivery 313 - Unified video resource control 314 - NAS based provisioning of ANX 315 - Remote connectivity check 317 4. Reference Model for PON Based Broadband Access Network 319 An overall end-to-end reference architecture of a PON access network 320 is depicted in Figure 1 and Figure 2 with ONT serving a single HGW, 321 and ONT/ONU serving multiples HGWs, respectively. An OLT may provide 322 FTTP and FTTB/C access at the same time but most likely not on the 323 same PON port. Specifically, the following PON cases are addressed in 324 the context of this reference architecture: 326 - BPON with Ethernet uplink to the NAS and ATM on the PON 327 side. 328 - GPON/XG-PON with Ethernet uplink to the NAS and Ethernet on 329 the PON side 331 In case of an Ethernet aggregation network that supports new QoS- 332 enabled IP services (including Ethernet multicast replication), the 333 architecture builds on the reference architecture specified in the 334 Broadband Forum (BBF) [TR-101]. The Ethernet aggregation network 335 between a NAS and an OLT may be degenerated to one or more direct 336 physical Ethernet links. 338 Given the industry move towards Ethernet as the new access and 339 aggregation technology for triple play services, the primary focus 340 throughout this document is on GPON/XG-PON and BPON with Ethernet 341 between the NAS and the OLT. 343 Access Customer 344 <---------Aggregation-------><-Prem-> 345 Network Network 347 +------------------+ 348 | Access Node | 349 | Complex (ANX) | 350 +---------+ +---+ +-----+ |+---+ +---+ | +---+ 351 | | +-|NAS|--|Eth |--||OLT|--|ONT|-|--|HGW| 352 NSP---+Regional | | +---+ |Agg | |+---+ +---+ | +---+ 353 |Broadband| | +---+ +-----+ +------------------+ 354 |Network |-+-|NAS| | 355 ASP---+ | | +---+ | 356 | | | +---+ | 357 +---------+ +-|NAS| | +---+ +---+ 358 +---| +--|ONT|--|HGW| 359 | +---+ +---+ 360 | 361 | +---+ +---+ 362 +---|ONT|--|HGW| 363 +---+ +---+ 364 HGW : Home Gateway 365 NAS : Network Access Server 366 PON : Passive Optical Network 367 OLT : Optical Line Terminal 368 ONT : Optical Network Terminal 370 Figure 1: Access Network with PON. 372 FE/GE/VDSL 373 +---+ +---+ 374 +----------------+ | |-|HGW| 375 +---------+ +-----+ | +-----+ +----+| | | +---+ 376 | | +-|NAS |--| |Eth |--|OLT||-- | | 377 NSP---+Regional | | +-----+ | |Agg | | || | |ONT| +---+ 378 | | | | | | | || | | or|-|HGW| 379 |Broadband| | +-----+ | +-----+ +----+| | |ONU| +---+ 380 |Network |-+-|NAS | +----------------+ | | | 381 ASP---+ | | +-----+ | | | +---+ 382 | | | +-----+ | | |-|HGW| 383 +---------+ +-|NAS | | +---+ +---+ 384 +-----+ | 385 | +---+ +---+ 386 +-|ONT|-|HGW| 387 +---+ +---+ 389 Figure 2: FTTP/FTTB/C with multi-subscriber ONT/ONU serving MTUs/MDUs. 390 The following sections describe the functional blocks and network 391 segments in the PON access reference architecture. 393 4.1. Functional Blocks 395 4.1.1. Home Gateway 397 The Home Gateway (HGW) connects the different Customer Premises 398 Equipment (CPE) to the ANX and the access network. In case of PON, 399 the HGW is a layer 3 router. In this case, the HGW performs IP 400 configuration of devices within the home via DHCP, and performs 401 Network Address and Port Translation (NAPT) between the LAN and WAN 402 side. In case of FTTP/B/C, the HGW connects to the ONT/ONU over an 403 Ethernet interface. That Ethernet interface could be over an Ethernet 404 physical port or over another medium. In case of FTTP, it is possible 405 to have a single box GPON CPE solution, where the ONT encompasses the 406 HGW functionality as well as the GPON adaptation function. 408 4.1.2. PON Access 410 PON access is composed of the ONT/ONU and OLT. PON ensures 411 physical connectivity between the ONT/ONU at the customer 412 premises and the OLT. PON framing can be BPON (in case of BPON) 413 or GPON (in case of GPON). The protocol encapsulation on BPON is 414 based on multi-protocol encapsulation over AAL5, defined in 415 [RFC2684]. This covers PPP over Ethernet (PPPoE, defined in 416 [RFC2516]), or bridged IP (IPoE). The protocol encapsulation on 417 GPON is always IPoE. In all cases, the connection between the AN 418 (OLT) and the NAS (or BNG) is assumed to be Ethernet in this 419 document. 421 4.1.3. Access Node Complex 423 This is composed of OLT and ONT/ONU and is defined in section 2. 425 4.1.4. Access Node Complex Uplink to the NAS 427 The ANX uplink connects the OLT to the NAS. The fundamental 428 requirements for the ANX uplink are to provide traffic aggregation, 429 Class of Service distinction and customer separation and 430 traceability. This can be achieved using an ATM or an Ethernet based 431 technology. The focus in this document is on Ethernet as stated 432 earlier. 434 4.1.5. Aggregation Network 436 The aggregation network provides traffic aggregation towards the NAS. 437 The Aggregation network is assumed to be Ethernet in this document. 439 4.1.6. Network Access Server 441 The NAS is a network device which aggregates multiplexed Subscriber 442 traffic from a number of ANXs. The NAS plays a central role in per- 443 subscriber policy enforcement and QoS. It is often referred to as a 444 Broadband Network Gateway (BNG) or Broadband Remote Access Server 445 (BRAS). A detailed definition of the NAS is given in [RFC2881]. The 446 NAS interfaces to the aggregation network by means of 802.1Q or 802.1 447 Q-in-Q Ethernet interfaces, and towards the Regional Network by means 448 of transport interfaces (e.g., GigE, PPP over SONET). The NAS 449 functionality corresponds to the BNG functionality described in 450 BroadBand Forum (BBF) TR-101 [TR-101]. In addition, the NAS supports 451 the Access Node Control functionality defined for the respective use 452 cases in this document. 454 4.1.7. Regional Network 456 The Regional Network connects one or more NAS and associated Access 457 Networks to Network Service Providers (NSPs) and Application Service 458 Providers (ASPs). The NSP authenticates access and provides and 459 manages the IP address to Subscribers. It is responsible for overall 460 service assurance and includes Internet Service Providers (ISPs). The 461 ASP provides application services to the application Subscriber 462 (gaming, video, content on demand, IP telephony, etc.). The NAS can 463 be part of the NSP network. Similarly, the NSP can be the ASP. 465 4.2. Access Node Complex Control Reference Architecture Options 467 Section 3 details the differences between xDSL access and PON access 468 and the implication of these differences on DSLAM control vs. OLT and 469 ONT/ONU (access node complex (ANX)) control. The following sections 470 describe two reference models: (1) ANCP+OMCI ANX control, and (2) 471 all-ANCP ANX control. That is, the two models differ in the ONT/ONU 472 control within the ANX. Implementations, out of the scope of this 473 document, may choose to implement one or the other based on the 474 ONT/ONU type and the capabilities of the ONT/ONU and OLT. It is 475 possible for an OLT or an OLT PON port to connect to ONTs/ONUs with 476 different capabilities and for these two models to co-exist on the 477 same OLT and same PON. Section 12 describes the differences between 478 OMCI and ANCP in controlling the ONU/ONT. 480 OMCI is designed as a protocol between the OLT and ONT/ONU. It 481 enables the OLT to configure and administer capabilities on the 482 ONT/ONU in BPON, GPON and XG-PON. ANCP is designed as a protocol 483 between the NAS and access node. It enables the NAS to enforce 484 dynamic policies on the access node, and the access node to report 485 events to the NAS among other functions. 487 4.2.1. ANCP+OMCI ANX Control 489 Figure 3 depicts the reference model for ANCP+OMCI ANX control. In 490 this model, ANCP is enabled between the NAS and a connected OLT, and 491 OMCI is enabled between the OLT and an attached ONT/ONU. NAS 492 communicates with the ANX via ANCP. The OLT acts as an ANCP/OMCI 493 gateway for communicating necessary events and policies between the 494 OLT and ONT/ONU within the ANX and for communicating relevant 495 policies and events between the ONT/ONU and the NAS. The 496 functionality performed by the OLT as ANCP/OMCI gateway will be 497 application dependent (e.g., multicast control, topology discovery) 498 and should be specified in a related specification. It should be 499 noted that some applications are expected to require ANCP and/or OMCI 500 extensions to map messages between OMCI and ANCP. OMCI extensions are 501 likely to be defined by the ITU-T. It should also be noted that OMCI, 502 in addition to configuration and administration, provides the 503 capability to report status changes on an ONT/ONU with AVC (Attribute 504 Value Change) notifications. When ONT/ONU's DSL or Ethernet UNI 505 attributes change, a related ME (management Entity) will send a 506 corresponding notification (AVC) to the OLT. The OLT interworks such 507 notification into an ANCP report and sends it to the connected NAS 508 via the ANCP session between the OLT and the NAS. As the ANCP report 509 contains information of ONT/ONU's UNI and OLT's PON port, NAS can 510 obtain accurate information of access topology. 511 +----------------------+ 512 | ANX | 513 +---------+ +---+ +---+ |+---+ +-------+ | +---+ 514 | | +-|NAS|--|Eth|--||OLT|--|ONU/ONT|-|-|HGW| 515 NSP---+Regional | | +---+ |Agg| |+---+ +-------+ | +---+ 516 |Broadband| | +---+ +---+ +----------------------+ 517 |Network |-+-|NAS| | 518 ASP---+ | | +---+ | 519 | | | +---+ | 520 +---------+ +-|NAS| | +-------+ +---+ 521 +---| +--|ONU/ONT|-|HGW| 522 | +-------+ +---+ 523 | +---+ +---+ 524 +--|ONT|-----|HGW| 525 +---+ +---+ 526 ANCP OMCI 527 +<--------------->+<----------->+ 529 HGW: Home Gateway 530 NAS: Network Access Server 531 PON: Passive Optical Network 532 OLT: Optical Line Terminal 533 ONT: Optical Network Terminal 534 ONU: Optical Network Unit 536 Figure 3: Access Network with single ANCP+OMCI access control 538 4.2.2. All-ANCP ANX Control 540 Figure 4 depicts the All-ANCP ANX control reference model. In this 541 model, an ANCP session is enabled between a NAS and a connected OLT, 542 and another ANCP session is enabled between the OLT and a connected 543 ONT/ONU. ANCP enables communication of policies and events between 544 the OLT and the ANX. The OLT acts as a gateway to relay policies and 545 events between the NAS and ONT/ONU within the ANX in addition to 546 communicating policies and events between the OLT and ONT/ONU. It 547 should be noted that in this model, OMCI(not shown) is expected to be 548 simultaneously enabled between the ONT and OLT, supporting existing 549 OMCI capabilities and applications on the PON, independent of ANCP or 550 applications intended to be supported by ANCP. 552 +----------------------+ 553 | Access Node Complex | 554 | (ANX) | 555 +---------+ +---+ +---+ |+---+ +-------+ | +---+ 556 | | +-|NAS|--|Eth|--||OLT|--|ONU/ONT| |--|HGW| 557 NSP---+Regional | | +---+ |Agg| |+---+ +-------+ | +---+ 558 |Broadband| | +---+ +---+ +----------------------+ 559 |Network |-+-|NAS| | 560 ASP---+ | | +---+ | 561 | | | +---+ | 562 +---------+ +-|NAS| | +-------+ +---+ 563 +---| +--|ONU/ONT|--|HGW| 564 | +-------+ +---+ 565 | 566 | +-------+ +---+ 567 +---|ONU/ONT|--|HGW| 568 +-------+ +---+ 570 ANCP ANCP 571 +<----------------->+<---------->+ 573 HGW: Home Gateway 574 NAS: Network Access Server 575 PON: Passive Optical Network 576 OLT: Optical Line Terminal 577 ONT: Optical Network Terminal 578 ONU: Optical Network Unit 580 Figure 4: All-ANCP ANX Reference Model 582 5. Concept of Access Node Control Mechanism for PON Based Access 584 The high-level communication framework for an Access Node Control 585 mechanism is shown in Figure 5 for the ALL-ANCP ANX control model. 586 The Access Node Control mechanism defines a quasi real-time, general- 587 purpose method for multiple network scenarios with an extensible 588 communication scheme, addressing the different use cases that are 589 described in the sections that follow. The access node control 590 mechanism is also extended to run between OLT and ONT/ONU. The 591 mechanism consists of control function, and reporting and/or 592 enforcement function. Controller function is used to receive status 593 information or admission requests from the reporting function. It is 594 also used to trigger a certain behavior in the network element where 595 the reporting and/or enforcement function resides. 597 The reporting function is used to convey status information to the 598 controller function that requires the information for executing local 599 functions. The enforcement function can be contacted by the 600 controller function to enforce a specific policy or trigger a local 601 action. The messages shown in Figure 5 show the conceptual message 602 flow. The actual use of these flows, and the times or frequencies 603 when these messages are generated depend on the actual use cases, 604 which are described in later sections. 606 +--------+ 607 | Policy | +----+ 608 | Server | +-----|ONT |------- HGW 609 +--------+ + +----+ +---+ 610 | + +----------|ONT|----HGW 611 | + | +---+ 612 | +----------------|-------------+ 613 +----+ | +----+ | +-----+ | +---+ 614 |NAS |---------------| | | | |-|----|HGW| 615 | |<------------->| | | | ONU | | +---+ 616 +----+ ANCP | |OLT |----------| | | 617 | | | | | | | +---+ 618 | | | |<------------->| |------|HGW| 619 | | +----+ ANCP +-----+ | +---+ 620 | +------------------------------+ 621 | | Access Node | 622 | Control Request | | 623 | ------------------>| Control Request | 624 | |-------------------->| 625 | | Control Response | 626 | Control Response |<------------------- | 627 |<-------------------| | 628 | |Admission Request | 629 | Admission Request |<--------------------| 630 |<-------------------| | 631 |Admission Response | | 632 |------------------->|Admission Response | 633 | |-------------------->| 634 |Information Report | | 635 |<-------------------| | 636 Access Node Control Access Node Control 637 Mechanism Mechanism 638 <--------------------><--------------------> 639 PPP, DHCP, IP 640 <------------------------------------------------------> 642 Figure 5: Conceptual message flow for Access Node Control mechanism 643 in all-ANCP ANX control model. 645 As discussed previously, in different PON deployment scenarios, ANCP 646 may be used in variant ways and may interwork with other protocols, 647 e.g., OMCI. In the ANCP+OMCI model described earlier, the NAS 648 maintains ANCP adjacency with the OLT while the OLT controls the 649 ONT/ONU via OMCI. The messages shown in Figure 6 show the conceptual 650 message flow for this model. The actual use of these flows, and the 651 times or frequencies when these messages are generated depend on the 652 actual use cases. 654 +--------+ 655 | Policy | 656 | Server | 657 +--------+ +---+ +---+ 658 | +---- |ONT|--------|HGW| 659 | | +---+ +---+ 660 | +--------------- |-------------+ 661 +----+ | +----+ | +-----+ | +---+ 662 |NAS |---------------| | | | |-|----|HGW| 663 | |<------------->| | | | ONU | | +---+ 664 +----+ ANCP | |OLT |----------| | | 665 | | | | | | | +---+ 666 | | | |<------------->| |------|HGW| 667 | | +----+ OMCI +-----+ | +---+ 668 | +-----------------------------+ 669 | | Access Node | 670 | Control Request | | 671 | ------------------>| Control Request | 672 | |-------------------->| 673 | | Control Response | 674 | Control Response |<------------------- | 675 |<-------------------| | 676 | |Admission Request | 677 | Admission Request |<--------------------| 678 |<-------------------| | 679 |Admission Response | | 680 |------------------->|Admission Response | 681 | |-------------------->| 682 |Information Report | | 683 |<-------------------| | 684 Access Node Control Operating Maintenance 685 Mechanism Control Interface (OMCI) 686 <--------------------><--------------------> 688 PPP, DHCP, IP 689 <-------------------------------------------------------> 691 Figure 6: Conceptual Message Flow for ANCP+OMCI ANX control model. 693 6. Multicast 695 With the rise of supporting IPTV services in a resource-efficient 696 way, multicast services are becoming increasingly important. 698 In order to gain bandwidth optimization with multicast, the 699 replication of multicast content per access-loop needs to be 700 distributed to the ANX. This can be done by ANX (OLT and ONT/ONU) 701 becoming multicast aware by implementing an IGMP [RFC3376] 702 snooping and/or proxy function [RFC4605]. The replication thus needs 703 to be distributed between NAS, aggregation nodes, and ANX. In case of 704 GPON, and in case of BPON with Ethernet uplink, this is very viable. 705 By introducing IGMP processing on the ANX and aggregation nodes, the 706 multicast replication process is now divided between the NAS, the 707 aggregation node(s) and ANX. This is in contrast to the ATM-based 708 model where NAS is the single element responsible for all multicast 709 control and replication. In order to ensure backward compatibility 710 with the ATM-based model, the NAS, aggregation node and ANX need to 711 behave as a single logical device. This logical device must have 712 exactly the same functionality as the NAS in the ATM 713 access/aggregation network. The Access Node Control Mechanism can be 714 used to make sure that this logical/functional equivalence is 715 achieved by exchanging the necessary information between the ANX and 716 the NAS. 718 An alternative to multicast awareness in the ANX is for the 719 subscriber to communicate the IGMP "join/leave" messages with the 720 NAS, while the ANX is being transparent to these messages. In this 721 scenario, the NAS can use ANCP to create replication state in the ANX 722 for efficient multicast replication. The NAS sends a single copy of 723 the multicast stream towards the ANX. The NAS can perform network- 724 based conditional access and multicast admission control on multicast 725 joins, and create replication state in the ANX if the request is 726 admitted by the NAS. 728 The following sections describe various use cases related to 729 multicast. 731 6.1. Multicast Conditional Access 733 In a Broadband FTTP/B/C access scenario, Service Providers may want 734 to dynamically control, at the network level, access to some 735 multicast flows on a per user basis. This may be used in order to 736 differentiate among multiple Service Offers or to realize/reinforce 737 conditional access based on customer subscription. Note that, in some 738 environments, application layer conditional access by means of 739 Digital Rights Management (DRM) for instance may provide sufficient 740 control so that network-based Multicast conditional access may not be 741 needed. However, network level access control may add to the service 742 security by preventing the subscriber from receiving a non-subscribed 743 channel. In addition, it enhances network security by preventing a 744 multicast stream from being sent on a link or a PON based on a non- 745 subscriber request. 747 Where network-based channel conditional access is desired, there are 748 two approaches. It can be done on the NAS along with bandwidth-based 749 admission control. The NAS can control the replication state on the 750 ANX based on the outcome of access and bandwidth based admission 751 control. This is covered in a later section. The other approach is to 752 provision the necessary conditional access information on the ANX 753 (ONT/ONU and/or OLT) so the ANX can perform the conditional access 754 decisions autonomously. For these cases, the NAS can use ANCP to 755 provision black and white lists as defined in [RFC5851] on the ANX so 756 that the ANX can decide locally to honor a join or not. It should be 757 noted that in the PON case, the ANX is composed of the ONT/ONU and 758 OLT. Thus, this information can be programmed on the ONT/ONU and/or 759 OLT. Programming this information on the ONT/ONU prevents 760 illegitimate joins from propagating further into the network. A third 761 approach, outside of the scope, may be to program the HGW with the 762 access list. A White list associated with an Access Port identifies 763 the multicast channels that are allowed to be replicated to that 764 port. A Black list associated with an Access Port identifies the 765 multicast channels that are not allowed to be replicated to that 766 port. It should be noted that the black list if not explicitly 767 programmed is the complement of the white list and vice versa. 769 If the ONT/ONU performs IGMP snooping and it is programmed with a 770 channel access list, the ONT/ONU will first check if the requested 771 multicast channel is part of a White list or a Black list associated 772 with the access port on which the IGMP join is received. If the 773 channel is part of a White list, the ONT/ONU will pass the join 774 request upstream towards the NAS. The ONT/ONU must not start 775 replicating the associated multicast stream to the access port if 776 such a stream is received until it gets confirmation that it can do 777 so from the upstream node (NAS or OLT). Passing the channel access 778 list is one of the admission control criteria whereas bandwidth-based 779 admission control is another. If the channel is part of a Black list, 780 the ONT/ONU can autonomously discard the message because the channel 781 is not authorized for that subscriber. 783 The ONT/ONU, in addition to forwarding the IGMP join, sends an ANCP 784 admission request to the OLT identifying the channel to be joined and 785 the premises. Premises identification to the OLT can be based on a 786 Customer-Port-ID that maps to the access port on the ONT/ONU and 787 known at the ONT/ONU and OLT. If the ONT/ONU has a white list and/or 788 a black list per premises, the OLT need not have such a list. If the 789 ONT/ONU does not have such a list, the OLT may be programmed with 790 such a list for each premises. In this latter case, the OLT would 791 perform the actions described earlier on the ONT/ONU. Once the 792 outcome of admission control (conditional access and bandwidth based 793 admission control) is determined by the OLT (either by interacting 794 with the NAS or locally), it is informed to the ONT/ONU. OLT 795 Bandwidth based admission control scenarios are defined in a later 796 section. 798 The White List and Black List can contain entries allowing: 800 - An exact match for a (*,G) Any Source Multicast (ASM) group 801 (e.g., ); 803 - An exact match for a (S,G) Source Specific Multicast 804 (SSM)channel (e.g., ); 806 - A mask-based range match for a (*,G) ASM group (e.g., 807 ); 809 - A mask-based range match for a (S,G) SSM channel (e.g., 810 ); 812 The use of a White list and Black list may be applicable, for 813 instance, to regular IPTV services (i.e., Broadcast TV) offered by an 814 Access Provider to broadband (e.g., FTTP) subscribers. For this 815 application, the IPTV subscription is typically bound to a specific 816 FTTP home, and the multicast channels that are part of the 817 subscription are well-known beforehand. Furthermore, changes to the 818 conditional access information are infrequent, since they are bound 819 to the subscription. Hence the ANX can be provisioned with the 820 conditional access information related to the IPTV service. 822 Instead of including the channel list(s) at the ONT/ONU, the OLT or 823 NAS can be programmed with these access lists. Having these access 824 lists on the ONT/ONU prevents forwarding of unauthorized joins to the 825 OLT or NAS, reducing unnecessary control load on these network 826 elements. Similarly, performing the access control at the OLT instead 827 of the NAS, if not performed on the ONT/ONU, will reduce unnecessary 828 control load on the NAS. 830 6.2. Multicast Admission Control 832 The successful delivery of Triple Play Broadband services is quickly 833 becoming a big capacity planning challenge for most of the Service 834 Providers nowadays. Solely increasing available bandwidth is not 835 always practical, cost-economical and/or sufficient to satisfy end- 836 user experience given not only the strict QoS requirements of unicast 837 applications like VoIP and Video on Demand, but also the fast growth 838 of multicast interactive applications such as "video conferencing", 839 digital TV, and digital audio. These applications typically require 840 low delay, low jitter, low packet loss and high bandwidth. These 841 applications are also typically "non-elastic", which means that they 842 operate at a fixed bandwidth, which cannot be dynamically adjusted to 843 the currently available bandwidth. 845 An Admission Control (AC) mechanism covering admission of multicast 846 traffic for the FTTP/B/C access is required in order to avoid over- 847 subscribing the available bandwidth and negatively impacting the end- 848 user experience. Before honoring a user request to join a new 849 multicast flow, the combination of ANX and NAS must ensure admission 850 control is performed to validate that there is enough video bandwidth 851 remaining on the PON, and on the uplink between the OLT and NAS to 852 carry the new flow (in addition to all other existing multicast and 853 unicast video traffic) and that there is enough video bandwidth for 854 the subscriber to carry that flow. The solution needs to cope with 855 multiple flows per premises and needs to allow bandwidth to be 856 dynamically shared across multicast and unicast video traffic per 857 subscriber, PON, and uplink (irrespective of whether unicast AC is 858 performed by the NAS, or by some off-path Policy Server). It should 859 be noted that the shared bandwidth between multicast and unicast 860 video is under operator control. That is, in addition to the shared 861 bandwidth, some video bandwidth could be dedicated to Video on 862 Demand, while other video bandwidth could be dedicated for multicast. 864 The focus in this document will be on multicast-allocated bandwidth 865 including the shared unicast and multicast bandwidth. Thus, 866 supporting admission control requires some form of synchronization 867 between the entities performing multicast AC (e.g., the ANX and/or 868 NAS), the entity performing unicast AC (e.g., the NAS or a Policy 869 Server), and the entity actually enforcing the multicast replication 870 (i.e., the NAS and the ANX). This synchronization can be achieved in 871 a number of ways: 873 - One approach is for the NAS to perform bandwidth based 874 admission control on all multicast video traffic and unicast 875 video traffic that requires using the shared bandwidth with 876 multicast. Based on the outcome of admission control, NAS then 877 controls the replication state on the ANX. The subscriber 878 generates an IGMP join for the desired stream on its logical 879 connection to the NAS. The NAS terminates the IGMP message, and 880 performs conditional access and bandwidth based admission 881 control on the IGMP request. The bandwidth admission control is 882 performed against the following: 884 1. Available video bandwidth on the link to OLT 886 2. Available video bandwidth on the PON interface 888 3. Available video bandwidth on the last mile (access-port on 889 the ONT/ONU). 891 The NAS can locally maintain and track video bandwidth it manages for 892 all the three levels mentioned above. The NAS can maintain 893 identifiers corresponding to the PON interface and the last mile 894 (customer interface). It also maintains a channel map, associating 895 every channel (or a group of channels sharing the same bandwidth 896 requirement) with a data rate. For instance, in case of 1:1 VLAN 897 representation of the premises, the outer tag (S-VLAN) could be 898 inserted by the ANX to correspond to the PON interface on the OLT, 899 and the inner-tag could be inserted by the ANX to correspond to the 900 access-line towards the customer. Bandwidth tracking and maintenance 901 for the PON interface and the last-mile could be done on these VLAN 902 identifiers. In case of N:1 representation, the single VLAN inserted 903 by ANX could correspond to the PON interface on the OLT. The access 904 loop is represented via Customer-Port-ID received in "Agent Circuit 905 Identifier" sub-option in DHCP messages. 907 The NAS can perform bandwidth accounting on received IGMP messages. 908 The video bandwidth is also consumed by any unicast video being 909 delivered to the CPE. NAS can perform video bandwidth accounting and 910 control on both IGMP messages and on requests for unicast video 911 streams when either all unicast admission control is done by the NAS 912 or an external policy server makes a request to the NAS for using 913 shared bandwidth with multicast as described later in the document. 915 This particular scenario assumes the NAS is aware of the bandwidth on 916 the PON, and under all conditions can track the changes in available 917 bandwidth on the PON. On receiving an IGMP Join message, NAS will 918 perform bandwidth check on the subscriber bandwidth. If this passes, 919 and the stream is already being forwarded on the PON by the OLT 920 (which also means that it is already forwarded by the NAS to the 921 OLT), NAS will admit the JOIN, update the available subscriber 922 bandwidth, and transmit an ANCP message to the OLT and in turn to the 923 ONT/ONU to start replication on the customer port. If the stream is 924 not already being replicated to the PON by the OLT, the NAS will also 925 check the available bandwidth on the PON, and if it is not already 926 being replicated to the OLT it will check the bandwidth on the link 927 towards the OLT. If this passes, the available PON bandwidth and the 928 bandwidth on the link towards the OLT are updated. The NAS adds the 929 OLT as a leaf to the multicast tree for that stream. On receiving the 930 message to start replication, the OLT will add the PON interface to 931 its replication state if the stream is not already being forwarded on 932 that PON. Also, the OLT will send an ANCP message to direct the 933 ONT/ONU to add or update its replication state with the customer port 934 for that channel. The interaction between ANX and NAS is shown in 935 Figures 7 and 8. For unicast video streams, application level 936 signaling from the CPE typically triggers an application server to 937 request bandwidth based admission control from a policy server. The 938 policy server can in turn interact with the NAS to request the 939 bandwidth for the unicast video flow if it needs to use shared 940 bandwidth with multicast. If the bandwidth is available, NAS will 941 reserve the bandwidth, update the bandwidth pools for subscriber 942 bandwidth, the PON bandwidth, and the bandwidth on the link towards 943 the OLT, and send a response to the policy server, which is 944 propagated back to the application server to start streaming. 945 Otherwise, the request is rejected. 947 +----+ 948 +------------- |ONT |------ HGW 949 + +----+ 950 + +----+ 951 + +--------- |ONT |------ HGW 952 +----+ +----+ + +----+ 953 |NAS |---------------| |------ 954 | |<------------->| | + +-----+ 955 +----+ ANCP |OLT | +--------- | |----- HGW 956 | | | | | 957 | | |<------------------>| ONU |------HGW 958 | +----+ ANCP | | +---+ 959 | | | |-----|HGW| 960 | | +-----+ +---+ 961 | 1.IGMP JOIN(S/*,G) | | 962 |<---------------------------------------------------------- | 963 2.| | | | 964 +=======================+ | | 965 [Access Control & ] | | 966 [Subscriber B/W ] | | 967 [PON B/W & OLT link B/W ] | | 968 [based Admission Control] | | 969 +=======================+ | | 970 | | | | 971 |-------------------> | | | 972 3.ANCP Replication-Start| | | 973 ( or Multicast | | | 974 |MAC,Customer-Port-ID>| --------------------> | | 975 | |4.ANCP Replication-Start | 976 | ( or Multicast MAC,Customer-Port-ID) 977 |-------------------> | | | 978 |5.Multicast Flow(S,G)| | | 979 |On Multicast VLAN |---------------------> | | 980 | |6.Multicast Flow (S,G) | | 981 | |forwarded on | | 982 | |Unidirectional | | 983 | | | | 984 | |on the PON by OLT |------------->| 985 7. Multicast Flow 986 orwarded on | 987 Customer-Port by| 988 |ONT/OLT. | 989 | | 991 Figure 7: Interactions for NAS based Multicast Admission Control (no 992 IGMP processing on ANX, and NAS maintains available video bandwidth 993 for PON) upon channel join. 995 +----+ 996 +------------- |ONT |----- HGW 997 + +----+ 998 + +----+ 999 + +--------- |ONT |----- HGW 1000 +----+ +----+ + +----+ 1001 |NAS |---------------| |------ 1002 | |<------------->| | + +-----+ 1003 +----+ ANCP |OLT | +--------- | |---- HGW 1004 | | | | | 1005 | | |<------------------>| ONU |-----HGW 1006 | +----+ ANCP | | +---+ 1007 | | | |-----|HGW| 1008 | | +-----+ +---+ 1009 | | | | 1010 | IGMP LEAVE(S/*,G) | | 1011 |<-----------------------------------------------------------| 1012 | | | | 1013 +====================+ | | | 1014 [Admission Control ] | | | 1015 [ ] | | | 1016 +====================+ | | | 1017 | | | | 1018 | | | | 1019 | | | | 1020 |-------------------> | | | 1021 ANCP Replication-Stop | | | 1022 ( or Multicast MAC,Customer-Port-ID) | | 1023 | | | | 1024 | |---------------------> | | 1025 | | ANCP Replication-Stop | | 1026 ( or Multicast MAC,Customer-Port-ID) 1028 Figure 8: Interactions for NAS based Multicast Admission Control (no 1029 IGMP processing on ANX, and NAS maintains available video bandwidth 1030 for PON) upon channel leave. 1032 - An alternate approach is required if the NAS is not aware of 1033 the bandwidth on the PON. In this case the OLT does the PON bandwidth 1034 management, and requests NAS to perform bandwidth admission control 1035 on subscriber bandwidth and the bandwidth on the link to the OLT. 1036 Following are operations of various elements: 1038 ANX operation: 1040 - ONT/ONU can snoop IGMP messages. If conditional access is 1041 configured and the channel is in the Black list (or it is not on the 1042 White list), ONT will drop the IGMP Join. If the channel passes the 1043 conditional access check, the ONT will forward the IGMP Join, and 1044 will send a bandwidth admission control request to the OLT. In case 1045 the multicast stream is already being received on the PON, the 1046 ONT/ONU does not forward the stream to the access port where IGMP is 1047 received till it has received a positive admission control response 1048 from the OLT. 1050 - OLT can snoop IGMP messages. It also receives a bandwidth 1051 admission control request from the ONT/ONU for the requested channel. 1052 It can be programmed with a channel bandwidth map. If the multicast 1053 channel is already being streamed on the PON, or the channel 1054 bandwidth is less than the multicast available bandwidth on the PON, 1055 the OLT forwards the IGMP request to the NAS and keeps track of the 1056 subscriber (identified by customer-Port-ID) as a receiver. If the 1057 channel is not already being streamed on the PON, but the PON has 1058 sufficient bandwidth for that channel, the OLT reduces the PON 1059 multicast video bandwidth by the channel bandwidth and may optionally 1060 add the PON to the multicast tree without activation for that 1061 channel. This is biased towards a forward expectation that the 1062 request will be accepted at the NAS. The OLT forwards the IGMP join 1063 to the NAS. It also sends a bandwidth admission request to the NAS 1064 identifying the channel, and the premises for which the request is 1065 made. It sets a timer for the subscriber multicast entry within which 1066 it expects to receive a request from the NAS that relates to this 1067 request. If the PON available bandwidth is less than the bandwidth 1068 of the requested channel, the OLT sends an admission response (with a 1069 reject) to the ONT/ONU, and does not forward the IGMP join to the 1070 NAS. 1072 NAS operation: 1074 The NAS receives the IGMP join from the subscriber on the subscriber 1075 connection. When NAS receives the admission control request from ANX 1076 (also signifying the bandwidth on the PON is available), it performs 1077 admission control against the subscriber available multicast 1078 bandwidth. If this check passes, and the NAS is already transmitting 1079 that channel to the OLT, the request is accepted. If the check passes 1080 and the NAS is not transmitting the channel to the OLT yet, it 1081 performs admission control against the multicast video available 1082 bandwidth (this includes the dedicated multicast bandwidth and the 1083 shared bandwidth between multicast and video on demand) on the 1084 link(s) to the OLT. If the check passes, the request is accepted, the 1085 available video bandwidth for the subscriber and downlink to the OLT 1086 are reduced by the channel bandwidth, and the NAS sends an ANCP 1087 admission control response (indicating accept) to the OLT, requesting 1088 the addition of the subscriber to the multicast tree for that 1089 channel. The OLT activates the corresponding multicast entry if not 1090 active and maintains state of the subscriber in the list of receivers 1091 for that channel. The OLT also sends an ANCP request to the ONT/ONU 1092 to enable reception of the multicast channel and forwarding to the 1093 subscriber access port. Otherwise, if the request is rejected, the 1094 NAS will send an admission reject to the OLT, which in turn removes 1095 the subscriber as a receiver for that channel (if it were added), and 1096 credits back the channel bandwidth to the PON video bandwidth if 1097 there is no other receiver on the PON for that channel. The 1098 interactions between ANX and NAS are shown in Figures 9 and 10. 1100 If the OLT does not receive a response from the NAS within a set 1101 timer, the OLT removes the subscriber from the potential list of 1102 receivers for the indicated channel. It also returns the allocated 1103 bandwidth to the PON available bandwidth if there are no other 1104 receivers. In this case, the NAS may send a response to the OLT with 1105 no matching entry as the entry has been deleted. The OLT must perform 1106 admission control against the PON available bandwidth and may accept 1107 the request and send an ANCP request to the ONT/ONU to activate the 1108 corresponding multicast entry as described earlier. If it does not 1109 accept the request, it will respond back to the NAS with a reject. 1110 The NAS shall credit back the channel bandwidth to the subscriber. It 1111 shall also stop sending the channel to the OLT if that subscriber was 1112 the last leaf on the multicast tree towards the OLT. 1114 On processing an IGMP leave, the OLT will send an ANCP request to NAS 1115 to release resources. NAS will release the subscriber bandwidth. If 1116 this leave causes the stream to be no longer required by the OLT, the 1117 NAS will update its replication state and release the bandwidth on 1118 the NAS to OLT link. 1120 If the subscriber makes a request for a unicast video stream (i.e., 1121 Video on Demand), the request results in appropriate application 1122 level signaling, which typically results in an application server 1123 requesting a policy server for bandwidth-based admission control for 1124 the VoD stream. The policy server after authorizing the request, can 1125 send a request to the NAS for the required bandwidth if it needs to 1126 use bandwidth that is shared with multicast. This request may be 1127 based on a protocol outside of the scope of this document. The NAS 1128 checks if the available video bandwidth (accounting for both 1129 multicast and unicast) per subscriber and for the link to the OLT is 1130 sufficient for the request. If it is, it temporarily reserves the 1131 bandwidth and sends an ANCP admission request to the OLT for the 1132 subscriber, indicating the desired VoD bandwidth. If the OLT has 1133 sufficient bandwidth on the corresponding PON, it reserves that 1134 bandwidth and returns an accept response to the NAS. If not, it 1135 returns a reject to the NAS. If the NAS receives an accept, it 1136 returns an accept to the policy server which in turn returns an 1137 accept to the application server, and the video stream is streamed to 1138 the subscriber. This interaction is shown in Figure 11. If the NAS 1139 does not accept the request from the policy server, it returns a 1140 reject. If the NAS receives a reject from the OLT, it returns the 1141 allocated bandwidth to the subscriber and the downlink to the OLT. 1143 +----+ 1144 +-------- |ONT |-------- HGW 1145 +----+ +----+ + +----+ 1146 |NAS |---------------| |------ 1147 | |<------------->|OLT | + +-----+ 1148 +----+ ANCP | | ANCP +--------- | ONU |------ HGW 1149 | +----+<------------------>+-----+-------HGW 1150 | | | | 1151 |1.IGMP Join(s/*,G) +=============+ +=============+ | 1152 |<------------------[IGMP Snooping]---------[IGMP snooping]--| 1153 | +=============+ +=============+ | 1154 | |2.Admission-Request | | 1155 | |(Flow,Customer-Port-ID) | | 1156 | |<---------------------- | | 1157 | 3.+===============+ | | 1158 | [ Access Ctrl ] | | 1159 | [ & PON B/W ] | | 1160 | [ Admission Ctrl] | | 1161 | +===============+ PASS | | 1162 |4.Admission-Request | | | 1163 | | | | 1165 |<--------------------| | | 1166 5.| | | | 1167 +=================+ | | | 1168 [Subscriber B/W ] | | | 1169 [& OLT link B/W ] | | | 1170 [Admission Ctrl ] | | | 1171 +=================+PASS | | | 1172 |6.Admission-Reply-Pass | | 1173 | | | 1174 |-------------------->| | | 1175 | 7.+========================+ | | 1176 | [Update Replication State] | | 1177 | +========================+ | | 1178 | | 8.Admission-Reply-Pass | | 1179 | |( | | 1180 | |----------------------> | | 1181 | | 9.+============+ | 1182 | | [Update Repl.] | 1183 | | [ State ] | 1184 | | +============+ | 1186 Figure 9: Interaction between NAS & ANX for Multicast Bandwidth 1187 Admission Control in the All-ANCP ANX control model upon success. 1188 Similar functionality will be required when OMCI is enabled between the 1189 OLT and ONT/ONU in the ANCP+OMCI ANX control model. In this latter case, 1190 the OLT will act as ANCP-OMCI gateway. 1192 +----+ 1193 +--------- |ONT |------ HGW 1194 +----+ +----+ + +----+ 1195 |NAS |---------------| |------ 1196 | |<------------->|OLT | + +-----+ 1197 +----+ ANCP | | ANCP +----------| ONU |----- HGW 1198 | +----+<----------------->+-----+------HGW 1199 | | | | 1200 |1.IGMP Join(s/*,G) +=============+ +=============+ | 1201 |<------------------[IGMP Snooping]--------[IGMP snooping]-- | 1202 | +=============+ +=============+ | 1203 | |2.Admission-Request | | 1204 | |(Flow,Customer-Port-ID) | | 1205 | |<---------------------- | | 1206 | 2.+===============+ | | 1207 | [ Access Ctrl ] | | 1208 | [ & PON B/W ] | | 1209 | [ Admission Ctrl] | | 1210 | +===============+ PASS | | 1211 |3.Admission-Request | | | 1212 | | | 1213 |<--------------------| | | 1214 4.| | | | 1215 +==================+ | | | 1216 [Subscriber B/W ] | | | 1217 [& OLT link B/W ] | | | 1218 [Admission Ctrl ] | | | 1219 +==================+FAIL | | 1220 | | | | 1221 |5.Admission-Reply-Fail | | 1222 | | | | 1223 |-------------------->| | | 1224 | 6.+==================+ | | 1225 | [Release PON B/W ] | | 1226 | [Remove Repl.State ] | | 1227 | +==================+ | | 1228 | | 7.Admission-Reply-Fail | | 1229 | | | | 1230 | |----------------------> | | 1231 | | 8.+============+ | 1232 | | [Remove Repl.] | 1233 | | [ State ] | 1234 | | +============+ | 1235 Figure 10: Interaction between NAS and ANX for Multicast Bandwidth 1236 Admission Control in the All-ANCP ANX control model upon failure. 1237 Similar functionality will be required when OMCI is enabled between the 1238 OLT and ONT/ONU in the ANCP+OMCI ANX control model. In this latter case, 1239 the OLT will act as ANCP-OMCI gateway. 1241 +------------+ 1. VoD Request 1242 | App. Server|<----------------------------------------------- 1243 | Server | 1244 +------------+ 1245 | 2. Admission-Request (VoD-Flow) 1246 +-------+ 1247 |Policy | 1248 |Server | 1249 +-------+ 1250 | + 1251 |<-|---3. Admission-Request 1252 | | 1253 + | 8. Admission-Reply 1254 +----+ + +----+ +-----+ 1255 |NAS |---------------|OLT |-------------|ONT |---HGW--CPE 1256 | |<------------->| | +-----+ | 1257 +----+ ANCP +----+ | | 1258 | | | | 1259 4.| | | | 1260 +=================+ | | | 1261 [Subscriber B/W ] | | | 1262 [& OLT link B/W ] | | | 1263 [Admission Ctrl ] | | | 1264 +=================+PASS | | | 1265 | | | | 1266 | 5.Admission-Request | | | 1267 |(Bandwidth,PON-Port-ID) | | 1268 |-------------------> | | | 1269 | | | | 1270 | 6.+===============+ | | 1271 | [ PON B/W ] | | 1272 | [ Admission Ctrl] | | 1273 | +===============+ PASS | | 1274 |7.Admission-Reply | | | 1275 | | | | 1276 |<------------------- | | | 1277 | | | | 1279 Figure 11: Interactions for VoD Bandwidth Admission Control in the 1280 All-ANCP ANX control model. Similar functionality will be required 1281 when OMCI is enabled between the OLT and ONT in the ANCP+OMCI ANX 1282 control model. In this latter case, the OLT will act as ANCP-OMCI 1283 gateway. 1285 -A third possible approach is where the ANX is assumed to have a full 1286 knowledge to make an autonomous decision on admitting or rejecting a 1287 multicast and a unicast join. With respect to the interaction between 1288 ONT/ONU and OLT, the procedure is similar to the first approach 1289 (i.e., NAS controlled replication). However, when the OLT receives an 1290 IGMP request from a subscriber, it performs admission control against 1291 that subscriber multicast video bandwidth (dedicated and shared with 1292 Video on Demand), the PON and uplink to the NAS. It should be noted 1293 in this case that if there are multiple NAS-OLT links, either the 1294 link on which the multicast stream must be sent is pre-determined, 1295 needs to be selected by the OLT based on downstream bandwidth from 1296 NAS to OLT and the selection is communicated to the NAS, or the OLT 1297 has to be ready to receive the stream on any link. If the check 1298 passes, the OLT updates the video available bandwidth per PON and 1299 subscriber. The OLT adds the subscriber to the list of receivers and 1300 the PON to the multicast tree, if it is not already on it. It also 1301 sends an ANCP request to the ONT/ONU to add the subscriber access 1302 port to that channel multicast tree, and sends an ANCP message to the 1303 NAS informing it of the subscriber and link available video bandwidth 1304 and the channel the subscriber joined. The NAS upon receiving the 1305 ANCP information message, updates the necessary information, 1306 including the OLT to the multicast tree if it is not already on it. 1307 It should be noted in this case that the ANCP message from the OLT to 1308 the NAS is being used to add the OLT to a multicast tree as opposed 1309 to an IGMP message. The IGMP message can also be sent by the OLT with 1310 the OLT acting as an IGMP proxy at the expense of added messages. In 1311 this option, the OLT acts as the network IGMP router for the 1312 subscriber. 1314 For unicast video streams, the policy server receiving an admission 1315 request from an application server, as described before, may query 1316 the OLT for admission control as it has all information. If the OLT 1317 has sufficient bandwidth for the stream it reserves that bandwidth 1318 for the subscriber, PON and OLT uplink to the NAS and returns an 1319 accept to the policy server. It also updates the NAS via an ANCP 1320 message of the subscriber available video bandwidth. If the OLT 1321 rejects the policy server request, it will return a reject to the 1322 policy server. 1324 It should be noted that if the policy server adjacency is with the 1325 NAS, the policy server may make the admission request to the NAS. The 1326 NAS then sends an ANCP admission request to the OLT on behalf of the 1327 policy server. The NAS returns an accept or reject to the policy server 1328 if it gets a reject or accept, respectively, from the OLT. 1330 6.3. Multicast Accounting 1332 It may be desirable to perform accurate per-user or per Access Loop 1333 time or volume based accounting. In case the ANX is performing the 1334 traffic replication process, it knows when replication of a multicast 1335 flow to a particular Access Port or user starts and stops. Multicast 1336 accounting can be addressed in two ways: 1338 - ANX keeps track of when replication starts or stops, and reports 1339 this information to the NAS for further processing. In this case, 1340 ANCP can be used to send the information from the ANX to the NAS. 1341 This can be done with the Information Report message. The NAS can 1342 then generate the appropriate time and/or volume accounting 1343 information per Access Loop and per multicast flow, to be sent to the 1344 accounting system. The ANCP requirements to support this approach are 1345 specified in [RFC5851]. If the replication function is distributed 1346 between the OLT and ONT/ONU, a query from the NAS will result in OLT 1347 generating a query to the ONT/ONU. 1349 - ANX keeps track of when replication starts or stops, and generates 1350 the time and/or volume based accounting information per Access Loop 1351 and per multicast flow, before sending it to a central accounting 1352 system for logging. Since ANX communicates with this accounting 1353 system directly, the approach does not require the use of ANCP. It is 1354 therefore beyond the scope of this document. It may also be desirable 1355 for the NAS to have the capability to asynchronously query the ANX to 1356 obtain an instantaneous status report related to multicast flows 1357 currently replicated by the ANX. Such a reporting functionality could 1358 be useful for troubleshooting and monitoring purposes. If the 1359 replication function in the ANX is distributed between the OLT and 1360 the ONT/ONU, then for some of the information required by the NAS 1361 (such as the list of access-ports on which a flow is being forwarded 1362 or list of flows being forwarded on an access-port), a query to the 1363 OLT from the NAS will result in a query from OLT to ONT/ONU. The OLT 1364 responds back to the NAS when it receives the response from the 1365 ONT/ONU. Also, if the list of PONs on which replication is happening 1366 for a multicast channel or the list of channels being replicated on a 1367 PON is what is desired, the OLT can return this information. 1369 7. Remote Connectivity Check 1371 In an end-to-end Ethernet aggregation network, end-to-end Ethernet 1372 OAM as specified in IEEE 802.1ag and ITU-T Recommendation Y.1730/1731 1373 can provide Access Loop connectivity testing and fault isolation. 1375 However, most HGWs do not yet support these standard Ethernet OAM 1376 procedures. Also, in a mixed Ethernet and ATM access network (e.g., 1377 Ethernet based aggregation upstream from the OLT, and BPON 1378 downstream), interworking functions for end-to-end OAM are not yet 1379 standardized or widely available. Until such mechanisms become 1380 standardized and widely available, Access Node Control mechanism 1381 between NAS and ANX can be used to provide a simple mechanism to test 1382 connectivity of an access-loop from the NAS. 1384 Triggered by a local management interface, the NAS can use the Access 1385 Node Control Mechanism (Control Request Message) to initiate an 1386 Access Loop test between Access Node and HGW or ONT/ONU. On reception 1387 of the ANCP message, the OLT can trigger native OAM procedures 1388 defined for BPON in [G.983.1] and for GPON in [G.984.1]. The Access 1389 Node can send the result of the test to the NAS via a Control 1390 Response message. 1392 8. Access Topology Discovery 1394 In order to avoid congestion in the network, manage and utilize the 1395 network resources better, and ensure subscriber fairness, NAS 1396 performs hierarchical shaping and scheduling of the traffic by 1397 modeling different congestion points in the network (such as the 1398 last-mile, access Node uplink, and the access facing port). 1400 Such mechanisms require that the NAS gains knowledge about the 1401 topology of the access network, the various links being used and 1402 their respective rates. Some of the information required is somewhat 1403 dynamic in nature (e.g., DSL line rate in case the last mile is xDSL 1404 based, e.g., in case of "PON fed DSLAMs" for FTTC/FTTB scenarios), 1405 hence cannot come from a provisioning and/or inventory management 1406 Operations Support System (OSS). Some of the information varies less 1407 frequently (e.g., capacity of the OLT uplink), but nevertheless needs 1408 to be kept strictly in sync between the actual capacity of the uplink 1409 and the image the NAS has of it. 1411 OSS systems are rarely able to enforce in a reliable and scalable 1412 manner the consistency of such data, notably across organizational 1413 boundaries under certain deployment scenarios. The Access Topology 1414 Discovery function allows the NAS to perform these advanced functions 1415 without having to depend on an error-prone and possibly complex 1416 integration with an OSS system. 1418 The rate of the access-loop can be communicated via ANCP (Information 1419 Report Message) from the ONT/ONU to the OLT in the All-ANCP ANX 1420 control model or via OMCI in the ANCP+OMCI ANX control model, and 1421 then from OLT to the NAS via ANCP. Additionally, during the time the 1422 DSL NT is active, data rate changes can occur due to environmental 1423 conditions (the DSL Access Loop can get "out of sync" and can retrain 1424 to a lower value, or the DSL Access Loop could use Seamless Rate 1425 Adaptation making the actual data rate fluctuate while the line is 1426 active). In this case, ANX sends an additional Information Report to 1427 the NAS each time the Access Loop attributes change above a threshold 1428 value. Existing DSL procedures are not applicable in this case 1429 because an adapted message flow and additional TLVs are needed. 1431 +--------+ 1432 | Policy | 1433 | Server | 1434 +--------+ +---+ +---+ 1435 | +-----------|ONT|---|HGW| 1436 | | +---+ +---+ 1437 | +--------------- |-----------------+ 1438 +----+ | +----+ | +-----+ | +---+ 1439 |NAS |------------ | | | | | |-|-|HGW| 1440 | |<----------> | | | | |ONT/ | | +---+ 1441 +----+ ANCP | |OLT |--------------|ONU | | 1442 | | | | | | | +---+ 1443 | | | |<----------------->| |---|HGW| 1444 | | +----+ OMCI +-----+ | +---+ 1445 | +----------------------------------+ 1446 | | Access Node | 1447 | | | 1448 | |------GPON Ranging------| 1449 | Port Status Message| ONT Port UP | 1450 |<------------------ |<-----------------------| 1451 |Port Configuration GPON Line/Service Profile| 1452 |------------------> |<---------------------->| 1453 | ONT/ONI Port UP| | 1454 |<------------------ | | 1455 | | | 1456 | ANCP | OMCI | 1457 <-------------------><----------------------->| 1458 PPP, DHCP, IP 1459 <------------------------------------------------------> 1461 Figure 12: Message Flow for the use case of Topology Discovery for 1462 the ANCP+OMCI access control model. 1464 Figure 12 depicts a message flow for topology discovery when using 1465 the ANCP+OMCI access control model. Basically, when an ONT/ONU gets 1466 connected to a PON, the OLT detects a new device and a GPON Ranging 1467 process starts. During this process the ONT/ONU becomes authorized by 1468 the OLT and identified by ONT/ONU ID, PON Port ID and max Bandwidth. 1469 This port status is reported via ANCP to the NAS and then potentially 1470 the policy server via another mechanism that is out of scope of this 1471 document. In a second step after GPON Service profile is assigned 1472 from OLT to ONT/ONU, the OLT reports the final status to NAS with 1473 information about service profile and other information such as the 1474 ONT/ONU port rate to the subscriber for instance. 1476 9. Access Loop Configuration 1477 Topology Discovery reports access port identification to NAS when 1478 sending an Access Port Discovery message. This informs NAS 1479 identification of PON port on an Access Node. Based on Access Port 1480 Identification and on customer identification, service related 1481 parameters could be configured on an OLT and an ONU/ONT. 1483 Service related parameters could be sent to OLT via ANCP before or 1484 after an ONU/ONT is up. Sending of ANCP loop Configuration messages 1485 from NAS can be triggered by a management system or by customer 1486 identification and authentication after Topology Discovery. It may be 1487 used for first time configuration (zero touch) or for 1488 updating/upgrading customer's profile like C-VLAN ID, S-VLAN ID, and 1489 service bandwidth. 1491 Parameters of the User to Network Interface (UNI), which is the 1492 subscriber interface to HGW/CPE of ONU/ONT, can also be configured 1493 via ANCP. When the ONU/ONT supports ANCP, parameters of the UNI on 1494 ONU/ONT are sent to the ONU/ONT via ANCP. If the ONU/ONT does not 1495 support ANCP, but only OMCI, parameters have to be sent from the NAS 1496 to the OLT via ANCP first. Then, the OLT translates such 1497 configuration into OMCI and sends it to the ONU/ONT. 1499 10. Security Considerations 1501 [RFC5713] lists the ANCP related security threats that could be 1502 encountered on the Access Node and the NAS. It develops a threat 1503 model for ANCP security, and lists the security functions that are 1504 required at the ANCP level. 1506 With Multicast handling as described in this document, ANCP protocol 1507 activity between the ANX and the NAS is triggered by join/leave 1508 requests coming from the end-user equipment. This could potentially 1509 be used for denial of service attack against the ANX and/or the NAS. 1511 To mitigate this risk, the NAS and ANX may implement control plane 1512 protection mechanisms such as limiting the number of multicast flows 1513 a given user can simultaneously join, or limiting the maximum rate of 1514 join/leave from a given user. 1516 Protection against invalid or unsubscribed flows can be deployed via 1517 provisioning black lists as close to the subscriber as possible 1518 (e.g., in the ONT). 1520 User activity logging for accounting or tracking purposes could raise 1521 privacy concerns if not appropriately protected. To protect such 1522 information, logging/accounting information can be exchanged with the 1523 corresponding server over a secure channel, and the information can 1524 be stored securely with policy-driven controlled access. 1526 11. Differences in ANCP applicability between DSL and PON 1528 As it currently stands, both ANCP framework [RFC5851] and protocol 1529 [RFC6320] are defined in context of DSL access. Due to inherent 1530 differences between PON and DSL access technologies, ANCP needs a few 1531 extensions for supporting the use-cases outlined in this document for 1532 PON based access. These specific differences and extensions are 1533 outlined below. 1535 - In PON, the access-node functionality is split between OLT and ONT. 1536 Therefore, ANCP interaction between NAS and AN translates to 1537 transactions between NAS and OLT and between OLT and ONT. The 1538 processing of ANCP messages (e.g., for multicast replication control) 1539 on the OLT can trigger generation of ANCP messages from OLT to ONT. 1540 Similarly, ANCP messages from ONT to the OLT can trigger ANCP 1541 exchange between the OLT and the NAS (e.g., admission-request 1542 messages). This is illustrated in the generic message flows in 1543 Figures 5 and 6 of section 5. In case of DSL, the ANCP exchange is 1544 contained between two network elements (NAS and the DSLAM). 1546 - The PON connection to the ONT is a shared medium between multiple 1547 ONTs on the same PON. The local-loop in case of DSL is point-to- 1548 point. In case of DSL access network, the access facing port on the 1549 NAS (i.e., port to the network between NAS and the DSLAM), and the 1550 access-facing ports on the DSLAM (i.e., customer's local-loop) are 1551 the two bandwidth constraint points that need to be considered for 1552 performing bandwidth based admission control for multicast video and 1553 VoD delivered to the customer. In case of PON access, in addition to 1554 the bandwidth constraint on the NAS to OLT facing ports, and the 1555 subscriber allocated bandwidth for video services, the bandwidth 1556 available on the PON for video is an additional constraint that needs 1557 to be considered for bandwidth based admission control. If the 1558 bandwidth control is centralized in NAS (as described in option 1 of 1559 section 6.2), then the NAS needs to support additional logic to 1560 consider available PON bandwidth before admitting a multicast request 1561 or a VoD request by the user. Accordingly, ANCP needs to identify the 1562 customer access port and the PON on which the customer ONT is. If the 1563 PON bandwidth control is performed on the OLT (as defined in second 1564 option in section 6.2), then additional ANCP request and response 1565 messages are required for NAS to query the OLT to determine available 1566 PON bandwidth when a request to admit a VOD flow is received on the 1567 NAS (as shown in Figure 9 in section 6.2) or for the OLT to inform 1568 the NAS what stream bandwidth is sent to the subscriber for the NAS 1569 to take appropriate action (e.g., bandwidth adjustment for various 1570 types of traffic). 1572 - In PON, the multicast replication can potentially be performed on 1573 three different network elements: (1) on the NAS (2) on the OLT for 1574 replication to multiple PON ports, and (3) on the ONT/ONU for 1575 replication to multiple customer ports. In case of DSL, the 1576 replication can potentially be performed on NAS and/or the DSLAM. 1577 Section 6.2 defines options for multicast replication in case of PON. 1578 In the first option, the multicast replication is done on the AN, but 1579 is controlled from NAS via ANCP (based on the reception of per- 1580 customer IGMP messages on the NAS). In this option, the NAS needs to 1581 supply to the OLT the set of PON-customer-IDs (as defined in section 1582 2) to which the multicast stream needs to be replicated. The PON- 1583 customer-ID identifies the OLT and the PON ports on the OLT as well 1584 as the ONT and the access-ports on the ONT where the multicast stream 1585 needs to be replicated. Upon receiving the request to update its 1586 multicast replication state, the OLT must update its replication 1587 state with the indicated PON ports, but may also need to interact 1588 with the ONT via ANCP to update the multicast replication state on 1589 the ONT with the set of access-ports (as indicated by the NAS). In 1590 case of DSL, the DSLAM only needs to update its own replication state 1591 based on the set of access-ports indicated by the NAS. 1593 - For reporting purposes, ANCP must enable the NAS to query the OLT 1594 for channels replicated on a PON or a list of PONs and to specific 1595 access ports. The latter should trigger the OLT to query the ONT for 1596 a list of channels being replicated on all access ports or on 1597 specific access ports to the premises. In DSL case, it is sufficient 1598 to query the DSLAM for a list of channels being replicated on an 1599 access port or a list of access ports. 1601 12. ANCP versus OMCI between the OLT and ONT/ONU 1603 ONT Management and Control Interface (OMCI) [OMCI] is specified for 1604 in-band ONT management via the OLT. This includes configuring 1605 parameters on the ONT/ONU. Such configuration can include adding an 1606 access port on the ONT to a multicast tree and the ONT to a multicast 1607 tree. Thus, OMCI can be a potential replacement for ANCP between the 1608 OLT and ONT/ONU, albeit it may not a be suitable protocol for dynamic 1609 transactions as required for the multicast application. 1611 If OMCI is selected to be enabled between the OLT and ONT/ONU to 1612 carry the same information elements that would be carried over ANCP, 1613 the OLT must perform the necessary translation between ANCP and OMCI 1614 for replication control messages received via ANCP. OMCI is an 1615 already available control channel, while ANCP requires a TCP/IP stack 1616 on the ONT/ONU that can be used by an ANCP client and accordingly it 1617 requires that the ONT/ONU be IP addressable for ANCP. Most ONTs/ONUs 1618 today have a TCP/IP stack used by certain applications (e.g., VoIP, 1619 IGMP snooping). ANCP may use the same IP address that is often 1620 assigned for VoIP or depending on the implementation may require a 1621 different address. Sharing the same IP address between VoIP and ANCP 1622 may have other network implications on how the VoIP agent is 1623 addressed and on traffic routing. For instance, the VoIP traffic 1624 to/from the ONT is often encapsulated in a VLAN-tagged Ethernet frame 1625 and switched at layer2 through the OLT to the NAS where it is routed. 1626 The VoIP agent in this case looks like another subscriber to the NAS. 1627 On the other hand, the ANCP session between the ONT and OLT is 1628 terminated at the OLT. Thus, the OLT must be able to receive/send IP 1629 traffic to/from the OLT, which will not work using this setting. 1630 Using a separate IP address for the purpose of ONT/ONU management or 1631 ANCP specifically may often be required when supporting ANCP. These 1632 considerations may favor OMCI in certain environments. However, OMCI 1633 will not allow some of the transactions required in approach 2, where 1634 the ONT/ONU sends unsolicited requests to the OLT rather than being 1635 queried or configured by OLT requests. 1637 13. IANA Considerations 1639 This document does not require actions by IANA. 1641 14. Acknowledgements 1643 The authors are thanksful to Rajesh Yadav and Francois Le Faucheur 1644 for valuable comments and discussions. 1646 15. References 1648 15.1. Normative References 1650 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 1651 and R. Wheeler, "A Method for Transmitting PPP Over 1652 Ethernet (PPPoE)", RFC 2516, February 1999. 1654 [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation 1655 over ATM Adaptation Layer 5", RFC 2684, September 1999. 1657 [RFC3376] Cain, B., et al, "Internet Group Management Interface, 1658 Version 3", RFC 3376, October 2002. 1660 [RFC4605] Fenner, W., et al, "Internet Group Management Protocol 1661 (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding 1662 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1664 15.2. Informative References 1666 [RFC2881] Mitton, D. and M. Beadles, "Network Access Server 1667 Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 1668 2000. 1670 [RFC5851] Ooghe, S., et al., "Framework and Requirements for Access 1671 Node Control Mechanism in Broadband Networks", RFC 5851, May 2010. 1673 [G.983.1] ITU-T G.983.1, "Broadband optical access systems based on 1674 Passive Optical Networks (PON)". 1676 [G.984.1] ITU-T G.984.1, "Gigabit-capable Passive Optical Networks 1677 (G-PON): General characteristics". 1679 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 1680 RFC3046, January 2011. 1682 [TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 1683 Aggregation", DSL Forum TR-101, May 2006. 1685 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, 1686 "Security Threats and Security Requirements for the Access Node 1687 Control Protocol (ANCP)", RFC 5713, January 2010. 1689 [OMCI] ITU-T G.984.4, "GPON ONT Management and Control Interface 1690 (OMCI) Specifications". 1692 [RFC6320] Taylor, T., et al, "Protocol for Access Node Control 1693 Mechanism in Broadband Networks", RFC 6320, October 2011. 1695 [G.987.3] ITU-T G.987.3, "10-Gigabit-capable passive optical 1696 networks(XG-PON): Transmission convergence (TC) layer specification". 1698 Authors' Addresses 1700 Nabil Bitar 1701 Verizon 1702 60 Sylvan Road 1703 Waltham, MA 02451 1704 Email: nabil.n.bitar@verizon.com 1706 Sanjay Wadhwa 1707 Alcatel-Lucent 1708 701 East Middlefield Road 1709 Mountain View, CA, 94043 1710 Email: sanjay.wadhwa@alcatel-lucent.com 1712 Thomas Haag 1713 Deutsche Telekom 1714 Email: HaagT@telekom.de 1716 Hongyu Li 1717 Huawei Technologies 1718 Email: hongyu.lihongyu@huawei.com