Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
RFC 6934
| Document | Type |
RFC
- Informational
(June 2013)
Was
draft-ietf-ancp-pon
(ancp WG)
|
|
|---|---|---|---|
| Authors | Dr. Nabil N. Bitar , Sanjay Wadhwa , Thomas Haag , Li Hongyu | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Ralph Droms | |
| Send notices to | (None) |
RFC 6934
gt;| Control Request |
| |-------------------->|
| | Control Response |
| Control Response |<------------------- |
|<-------------------| |
| |Admission Request |
| Admission Request |<--------------------|
|<-------------------| |
|Admission Response | |
|------------------->|Admission Response |
| |-------------------->|
|Information Report | |
|<-------------------| |
Access Node Control Access Node Control
Mechanism Mechanism
<--------------------><-------------------->
PPP, DHCP, IP
<------------------------------------------------------>
Figure 5: Conceptual Message Flow for Access Node Control Mechanism
in All-ANCP ANX Control Model
Bitar, et al. Informational [Page 14]
RFC 6934 ANCP in PON-Based Networks June 2013
As discussed previously, in different PON deployment scenarios, ANCP
may be used in variant ways and may interwork with other protocols,
e.g., OMCI. In the ANCP+OMCI control model described earlier, the
NAS maintains ANCP adjacency with the OLT while the OLT controls the
ONT/ONU via OMCI. The messages shown in Figure 6 show the conceptual
message flow for this model. The actual use of these flows, and the
times or frequencies when these messages are generated, depend on the
actual use cases.
+--------+
| Policy |
| Server |
+--------+ +---+ +---+
| +---- |ONT|--------|HGW|
| | +---+ +---+
| +--------------- |-------------+
+----+ | +----+ | +-----+ | +---+
|NAS |---------------| | | | |-|----|HGW|
| |<------------->| | | | ONU | | +---+
+----+ ANCP | |OLT |------<PON>----| | |
| | | | | | | +---+
| | | |<------------->| |------|HGW|
| | +----+ OMCI +-----+ | +---+
| +-----------------------------+
| | Access Node |
| Control Request | |
| ------------------>| Control Request |
| |-------------------->|
| | Control Response |
| Control Response |<------------------- |
|<-------------------| |
| |Admission Request |
| Admission Request |<--------------------|
|<-------------------| |
|Admission Response | |
|------------------->|Admission Response |
| |-------------------->|
|Information Report | |
|<-------------------| |
Access Node Control Operating Maintenance
Mechanism Control Interface (OMCI)
<--------------------><-------------------->
PPP, DHCP, IP
<------------------------------------------------------->
Figure 6: Conceptual Message Flow for ANCP+OMCI ANX Control Model
Bitar, et al. Informational [Page 15]
RFC 6934 ANCP in PON-Based Networks June 2013
6. Multicast
With the rise of supporting IPTV services in a resource-efficient
way, multicast services are becoming increasingly important.
In order to gain bandwidth optimization with multicast, the
replication of multicast content per access loop needs to be
distributed to the ANX. This can be done by ANX (OLT and ONT/ONU)
becoming multicast aware by implementing an IGMP [RFC3376] snooping
and/or proxy function [RFC4605]. The replication thus needs to be
distributed between NAS, aggregation nodes, and ANX. In the case of
GPON and in the case of BPON with Ethernet uplink, this is very
viable. By introducing IGMP processing on the ANX and aggregation
nodes, the multicast replication process is now divided between the
NAS, the aggregation node(s), and ANX. This is in contrast to the
ATM-based model where NAS is the single element responsible for all
multicast control and replication. In order to ensure backward
compatibility with the ATM-based model, the NAS, aggregation node,
and ANX need to behave as a single logical device. This logical
device must have exactly the same functionality as the NAS in the ATM
access/aggregation network. The Access Node Control Mechanism can be
used to make sure that this logical/functional equivalence is
achieved by exchanging the necessary information between the ANX and
the NAS.
An alternative to multicast awareness in the ANX is for the
subscriber to communicate the IGMP "join/leave" messages with the
NAS, while the ANX is being transparent to these messages. In this
scenario, the NAS can use ANCP to create replication state in the ANX
for efficient multicast replication. The NAS sends a single copy of
the multicast stream towards the ANX. The NAS can perform network-
based conditional access and multicast admission control on multicast
joins and create replication state in the ANX if the request is
admitted by the NAS.
The following sections describe various use cases related to
multicast.
6.1. Multicast Conditional Access
In a broadband FTTP/B/C access scenario, service providers may want
to dynamically control, at the network level, access to some
multicast flows on a per user basis. This may be used in order to
differentiate among multiple Service Offers or to realize/reinforce
conditional access based on customer subscription. Note that, in
some environments, application-layer conditional access by means of
Digital Rights Management (DRM), for instance, may provide sufficient
control so that network-based multicast conditional access may not be
Bitar, et al. Informational [Page 16]
RFC 6934 ANCP in PON-Based Networks June 2013
needed. However, network-level access control may add to the service
security by preventing the subscriber from receiving a non-subscribed
channel. In addition, it enhances network security by preventing a
multicast stream from being sent on a link or a PON based on a non-
subscriber request.
Where network-based channel conditional access is desired, there are
two approaches. First, it can be done on the NAS along with
bandwidth-based admission control. The NAS can control the
replication state on the ANX based on the outcome of access and
bandwidth-based admission control. This is covered in a later
section. A second approach is to provision the necessary conditional
access information on the ANX (ONT/ONU and/or OLT) so the ANX can
perform the conditional access decisions autonomously. For these
cases, the NAS can use ANCP to provision black and white lists as
defined in [RFC5851] on the ANX so that the ANX can decide locally to
honor a join or not. It should be noted that in the PON case, the
ANX is composed of the ONT/ONU and OLT. Thus, this information can
be programmed on the ONT/ONU and/or OLT. Programming this
information on the ONT/ONU prevents illegitimate joins from
propagating further into the network. A third approach, outside of
the scope of this document, may be to program the HGW with the access
list. A white list associated with an Access Port identifies the
multicast channels that are allowed to be replicated to that port. A
black list associated with an Access Port identifies the multicast
channels that are not allowed to be replicated to that port. It
should be noted that the black list, if not explicitly programmed, is
the complement of the white list and vice versa.
If the ONT/ONU performs IGMP snooping and is programmed with a
channel access list, the ONT/ONU will first check if the requested
multicast channel is part of a white list or a black list associated
with the Access Port on which the IGMP join is received. If the
channel is part of a white list, the ONT/ONU will pass the join
request upstream towards the NAS. The ONT/ONU must not start
replicating the associated multicast stream to the Access Port if
such a stream is received until it gets confirmation that it can do
so from the upstream node (NAS or OLT). Passing the channel access
list is one of the admission control criteria whereas bandwidth-based
admission control is another. If the channel is part of a black
list, the ONT/ONU can autonomously discard the message because the
channel is not authorized for that subscriber.
The ONT/ONU, in addition to forwarding the IGMP join, sends an ANCP
admission request to the OLT identifying the channel to be joined and
the premises. Premises identification to the OLT can be based on a
Customer-Port-ID that maps to the Access Port on the ONT/ONU and is
known at the ONT/ONU and OLT. If the ONT/ONU has a white list and/or
Bitar, et al. Informational [Page 17]
RFC 6934 ANCP in PON-Based Networks June 2013
a black list per premises, the OLT need not have such a list. If the
ONT/ONU does not have such a list, the OLT may be programmed with
such a list for each premises. In the latter case, the OLT would
perform the actions described earlier on the ONT/ONU. Once the
outcome of admission control (conditional access and bandwidth-based
admission control) is determined by the OLT (either by interacting
with the NAS or locally), it is informed to the ONT/ONU. OLT
bandwidth-based admission control scenarios are defined in a later
section.
The white list and black list can contain entries allowing:
- An exact match for a (*,G) Any-Source Multicast (ASM) group (e.g.,
<G=g.h.i.l>)
- An exact match for a (S,G) Source-Specific Multicast (SSM) channel
(e.g., <S=s.t.u.v,G=g.h.i.l>)
- A mask-based range match for a (*,G) ASM group (e.g.,
<G=g.h.i.l/Mask>)
- A mask-based range match for a (S,G) SSM channel (e.g.,
<S=s.t.u.v,G=g.h.i.l/Mask>)
The use of a white list and black list may be applicable, for
instance, to regular IPTV services (i.e., Broadcast TV) offered by an
Access Provider to broadband (e.g., FTTP) subscribers. For this
application, the IPTV subscription is typically bound to a specific
FTTP home, and the multicast channels that are part of the
subscription are well-known beforehand. Furthermore, changes to the
conditional access information are infrequent, since they are bound
to the subscription. Hence, the ANX can be provisioned with the
conditional access information related to the IPTV service.
Instead of including the channel list(s) at the ONT/ONU, the OLT or
NAS can be programmed with these access lists. Having these access
lists on the ONT/ONU prevents forwarding of unauthorized joins to the
OLT or NAS, reducing unnecessary control load on these network
elements. Similarly, performing the access control at the OLT
instead of the NAS, if not performed on the ONT/ONU, will reduce
unnecessary control load on the NAS.
6.2. Multicast Admission Control
The successful delivery of triple-play broadband services is quickly
becoming a big capacity-planning challenge for most of the service
providers nowadays. Solely increasing available bandwidth is not
always practical, cost-economical, and/or sufficient to satisfy end-
Bitar, et al. Informational [Page 18]
RFC 6934 ANCP in PON-Based Networks June 2013
user experience given not only the strict QoS requirements of unicast
applications like VoIP and Video on Demand but also the fast growth
of multicast interactive applications such as "video conferencing",
digital TV, and digital audio. These applications typically require
low delay, low jitter, low packet loss, and high bandwidth. These
applications are also typically "non-elastic", which means that they
operate at a fixed bandwidth that cannot be dynamically adjusted to
the currently available bandwidth.
An Admission Control (AC) Mechanism covering admission of multicast
traffic for the FTTP/B/C access is required in order to avoid over-
subscribing the available bandwidth and negatively impacting the end-
user experience. Before honoring a user request to join a new
multicast flow, the combination of ANX and NAS must ensure admission
control is performed to validate that there is enough video bandwidth
remaining on the PON and on the uplink between the OLT and NAS to
carry the new flow (in addition to all other existing multicast and
unicast video traffic) and that there is enough video bandwidth for
the subscriber to carry that flow. The solution needs to cope with
multiple flows per premises and needs to allow bandwidth to be
dynamically shared across multicast and unicast video traffic per
subscriber, PON, and uplink (irrespective of whether unicast AC is
performed by the NAS or by some off-path policy server). It should
be noted that the shared bandwidth between multicast and unicast
video is under operator control. That is, in addition to the shared
bandwidth, some video bandwidth could be dedicated to Video on
Demand, while other video bandwidth could be dedicated for multicast.
The focus in this document is on multicast-allocated bandwidth
including the shared unicast and multicast bandwidth. Thus,
supporting admission control requires some form of synchronization
between the entities performing multicast AC (e.g., the ANX and/or
NAS), the entity performing unicast AC (e.g., the NAS or a policy
server), and the entity actually enforcing the multicast replication
(i.e., the NAS and the ANX). This synchronization can be achieved in
a number of ways.
One approach is for the NAS to perform bandwidth-based admission
control on all multicast video traffic and unicast video traffic that
requires using the shared bandwidth with multicast. Based on the
outcome of admission control, NAS then controls the replication state
on the ANX. The subscriber generates an IGMP join for the desired
stream on its logical connection to the NAS. The NAS terminates the
IGMP message and performs conditional access and bandwidth-based
admission control on the IGMP request. The bandwidth admission
control is performed against the following:
Bitar, et al. Informational [Page 19]
RFC 6934 ANCP in PON-Based Networks June 2013
1. Available video bandwidth on the link to OLT
2. Available video bandwidth on the PON interface
3. Available video bandwidth on the last mile (Access Port on the
ONT/ONU)
The NAS can locally maintain and track video bandwidth it manages for
all the three levels mentioned above. The NAS can maintain
identifiers corresponding to the PON interface and the last mile
(customer interface). It also maintains a channel map, associating
every channel (or a group of channels sharing the same bandwidth
requirement) with a data rate. For instance, in the case of 1:1 VLAN
representation of the premises, the outer tag (S-VLAN) could be
inserted by the ANX to correspond to the PON interface on the OLT,
and the inner-tag could be inserted by the ANX to correspond to the
access-line towards the customer. Bandwidth tracking and maintenance
for the PON interface and the last mile could be done on these VLAN
identifiers. In the case of N:1 representation, the single VLAN
inserted by ANX could correspond to the PON interface on the OLT.
The access loop is represented via Customer-Port-ID received in the
"Agent Circuit ID" sub-option in DHCP messages.
The NAS can perform bandwidth accounting on received IGMP messages.
The video bandwidth is also consumed by any unicast video being
delivered to the CPE. NAS can perform video bandwidth accounting and
control on both IGMP messages and on requests for unicast video
streams when either all unicast admission control is done by the NAS
or an external policy server makes a request to the NAS for using
shared bandwidth with multicast as described later in the document.
This particular scenario assumes the NAS is aware of the bandwidth on
the PON and can track the changes in available bandwidth on the PON
under all conditions. On receiving an IGMP join message, NAS will
perform bandwidth check on the subscriber bandwidth. If this passes
and the stream is already being forwarded on the PON by the OLT
(which also means that it is already forwarded by the NAS to the
OLT), NAS will admit the join, update the available subscriber
bandwidth, and transmit an ANCP message to the OLT and in turn to the
ONT/ONU to start replication on the customer port. If the stream is
not already being replicated to the PON by the OLT, the NAS will also
check the available bandwidth on the PON, and if it is not already
being replicated to the OLT, it will check the bandwidth on the link
towards the OLT. If this passes, the available PON bandwidth and the
bandwidth on the link towards the OLT are updated. The NAS adds the
OLT as a leaf to the multicast tree for that stream. On receiving
the message to start replication, the OLT will add the PON interface
to its replication state if the stream is not already being forwarded
Bitar, et al. Informational [Page 20]
RFC 6934 ANCP in PON-Based Networks June 2013
on that PON. Also, the OLT will send an ANCP message to direct the
ONT/ONU to add or update its replication state with the customer port
for that channel. The interaction between ANX and NAS is shown in
Figures 7 and 8. For unicast video streams, application-level
signaling from the CPE typically triggers an application server to
request bandwidth-based admission control from a policy server. The
policy server can, in turn, interact with the NAS to request the
bandwidth for the unicast video flow if it needs to use shared
bandwidth with multicast. If the bandwidth is available, NAS will
reserve the bandwidth; update the bandwidth pools for subscriber
bandwidth, the PON bandwidth, and the bandwidth on the link towards
the OLT; and send a response to the policy server, which is
propagated back to the application server to start streaming.
Otherwise, the request is rejected.
Bitar, et al. Informational [Page 21]
RFC 6934 ANCP in PON-Based Networks June 2013
+----+
+---<PON>---------- |ONT |------ HGW
+ +----+
+ +----+
+ +--------- |ONT |------ HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->| | + +-----+
+----+ ANCP |OLT | +--------- | |----- HGW
| | | | |
| | |<------------------>| ONU |------HGW
| +----+ ANCP | | +---+
| | | |-----|HGW|
| | +-----+ +---+
| 1.IGMP join (S/*,G) | |
|<---------------------------------------------------------- |
2.| | | |
+=======================+ | |
[Access Control & ] | |
[Subscriber B/W ] | |
[PON B/W & OLT link B/W ] | |
[based Admission Control] | |
+=======================+ | |
| | | |
|-------------------> | | |
3.ANCP Replication-Start| | |
(<S/*,G> or Multicast | | |
|MAC,Customer-Port-ID)| --------------------> | |
| |4.ANCP Replication-Start |
| (<S/*,G> or Multicast MAC,Customer-Port-ID)
|-------------------> | | |
|5.Multicast Flow(S,G)| | |
|on Multicast VLAN |---------------------> | |
| |6.Multicast Flow (S,G) | |
| |forwarded on | |
| |Unidirectional | |
| |<Multicast GEM-PORT> | |
| |on the PON by OLT |------------->|
7.Multicast Flow
forwarded on |
Customer-Port by|
|ONT/OLT. |
| |
Figure 7: Interactions for NAS-Based Multicast Admission Control
(No IGMP Processing on ANX and NAS Maintains Available Video
Bandwidth for PON) upon Channel Join
Bitar, et al. Informational [Page 22]
RFC 6934 ANCP in PON-Based Networks June 2013
+----+
+---<PON>---------- |ONT |----- HGW
+ +----+
+ +----+
+ +--------- |ONT |----- HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->| | + +-----+
+----+ ANCP |OLT | +--------- | |---- HGW
| | | | |
| | |<------------------>| ONU |-----HGW
| +----+ ANCP | | +---+
| | | |-----|HGW|
| | +-----+ +---+
| | | |
| IGMP leave (S/*,G) | |
|<-----------------------------------------------------------|
| | | |
+====================+ | | |
[Admission Control ] | | |
[<Resource Released> ] | | |
+====================+ | | |
| | | |
| | | |
| | | |
|-------------------> | | |
ANCP Replication-Stop | | |
(<S/*,G> or Multicast MAC,Customer-Port-ID) | |
| | | |
| |---------------------> | |
| | ANCP Replication-Stop | |
(<S/*,G> or Multicast MAC,Customer-Port-ID)
Figure 8: Interactions for NAS-Based Multicast Admission Control
(No IGMP Processing on ANX and NAS Maintains Available Video
Bandwidth for PON) upon Channel Leave
An alternate approach is required if the NAS is not aware of the
bandwidth on the PON. In this case, the OLT does the PON bandwidth
management and requests NAS to perform bandwidth admission control on
subscriber bandwidth and the bandwidth on the link to the OLT.
Following are operations of various elements:
ANX operation:
- ONT/ONU can snoop IGMP messages. If conditional access is
configured and the channel is in the black list (or it is not on
the white list), ONT will drop the IGMP join. If the channel
Bitar, et al. Informational [Page 23]
RFC 6934 ANCP in PON-Based Networks June 2013
passes the conditional access check, the ONT will forward the IGMP
join and will send a bandwidth admission control request to the
OLT. If the multicast stream is already being received on the
PON, the ONT/ONU does not forward the stream to the Access Port
where IGMP is received until it has received a positive admission
control response from the OLT.
- OLT can snoop IGMP messages. It also receives a bandwidth
admission control request from the ONT/ONU for the requested
channel. It can be programmed with a channel bandwidth map. If
the multicast channel is already being streamed on the PON or the
channel bandwidth is less than the available multicast bandwidth
on the PON, the OLT forwards the IGMP request to the NAS and keeps
track of the subscriber (identified by Customer-Port-ID) as a
receiver. If the channel is not already being streamed on the PON
but the PON has sufficient bandwidth for that channel, the OLT
reduces the PON multicast video bandwidth by the channel bandwidth
and may optionally add the PON to the multicast tree without
activation for that channel. This is biased towards a forward
expectation that the request will be accepted at the NAS. The OLT
forwards the IGMP join to the NAS. It also sends a bandwidth
admission request to the NAS identifying the channel and the
premises for which the request is made. It sets a timer for the
subscriber multicast entry within which it expects to receive a
request from the NAS that relates to this request. If the
available PON bandwidth is less than the bandwidth of the
requested channel, the OLT sends an admission response (with a
reject) to the ONT/ONU and does not forward the IGMP join to the
NAS.
NAS operation:
The NAS receives the IGMP join from the subscriber on the subscriber
connection. When NAS receives the admission control request from ANX
(also signifying the bandwidth on the PON is available), it performs
admission control against the subscriber's available multicast
bandwidth. If this check passes, and the NAS is already transmitting
that channel to the OLT, the request is accepted. If the check
passes and the NAS is not transmitting the channel to the OLT yet, it
performs admission control against the available multicast video
bandwidth (this includes the dedicated multicast bandwidth and the
shared bandwidth between multicast and Video on Demand) on the
link(s) to the OLT. If the check passes, the request is accepted,
the available video bandwidth for the subscriber and downlink to the
OLT are reduced by the channel bandwidth, and the NAS sends an ANCP
admission control response (indicating accept) to the OLT, requesting
the addition of the subscriber to the multicast tree for that
channel. The OLT activates the corresponding multicast entry if not
Bitar, et al. Informational [Page 24]
RFC 6934 ANCP in PON-Based Networks June 2013
active and maintains state of the subscriber in the list of receivers
for that channel. The OLT also sends an ANCP request to the ONT/ONU
to enable reception of the multicast channel and forwarding to the
subscriber Access Port. Otherwise, if the request is rejected, the
NAS will send an admission reject to the OLT, which, in turn, removes
the subscriber as a receiver for that channel (if it was added) and
credits back the channel bandwidth to the PON video bandwidth if
there is no other receiver on the PON for that channel. The
interactions between ANX and NAS are shown in Figures 9 and 10.
If the OLT does not receive a response from the NAS within a set
timer, the OLT removes the subscriber from the potential list of
receivers for the indicated channel. It also returns the allocated
bandwidth to the available PON bandwidth if there are no other
receivers. In this case, the NAS may send a response to the OLT with
no matching entry as the entry has been deleted. The OLT must
perform admission control against the available PON bandwidth and may
accept the request and send an ANCP request to the ONT/ONU to
activate the corresponding multicast entry as described earlier. If
it does not accept the request, it will respond back to the NAS with
a reject. The NAS shall credit back the channel bandwidth to the
subscriber. It shall also stop sending the channel to the OLT if
that subscriber was the last leaf on the multicast tree towards the
OLT.
On processing an IGMP leave, the OLT will send an ANCP request to NAS
to release resources. NAS will release the subscriber bandwidth. If
this leave causes the stream to be no longer required by the OLT, the
NAS will update its replication state and release the bandwidth on
the NAS to OLT link.
If the subscriber makes a request for a unicast video stream (i.e.,
Video on Demand), the request results in appropriate application-
level signaling, which typically results in an application server
requesting a policy server for bandwidth-based admission control for
the VoD stream. After authorizing the request, the policy server can
send a request to the NAS for the required bandwidth if it needs to
use bandwidth that is shared with multicast. This request may be
based on a protocol outside of the scope of this document. The NAS
checks if the available video bandwidth (accounting for both
multicast and unicast) per subscriber and for the link to the OLT is
sufficient for the request. If it is, it temporarily reserves the
bandwidth and sends an ANCP admission request to the OLT for the
subscriber, indicating the desired VoD bandwidth. If the OLT has
sufficient bandwidth on the corresponding PON, it reserves that
bandwidth and returns an accept response to the NAS. If not, it
returns a reject to the NAS. If the NAS receives an accept, it
returns an accept to the policy server, which, in turn, returns an
Bitar, et al. Informational [Page 25]
RFC 6934 ANCP in PON-Based Networks June 2013
accept to the application server, and the video stream is streamed to
the subscriber. This interaction is shown in Figure 11. If the NAS
does not accept the request from the policy server, it returns a
reject. If the NAS receives a reject from the OLT, it returns the
allocated bandwidth to the subscriber and the downlink to the OLT.
It should be noted that similar functionality to that described in
this section and depicted in Figures 9, 10, and 11 will be required
when OMCI is enabled between the OLT and ONT/ONU in the ANCP+OMCI ANX
control model. In the latter case, the OLT will act as an ANCP-OMCI
gateway.
Bitar, et al. Informational [Page 26]
RFC 6934 ANCP in PON-Based Networks June 2013
+----+
+-------- |ONT |-------- HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->|OLT | + +-----+
+----+ ANCP | | ANCP +--------- | ONU |------ HGW
| +----+<------------------>+-----+-------HGW
| | | |
|1.IGMP join(S/*,G) +=============+ +=============+ |
|<------------------[IGMP Snooping]---------[IGMP snooping]--|
| +=============+ +=============+ |
| |2.Admission-Request | |
| |(Flow,Customer-Port-ID) | |
| |<---------------------- | |
| 3.+===============+ | |
| [ Access Ctrl ] | |
| [ & PON B/W ] | |
| [ Admission Ctrl] | |
| +===============+ PASS | |
|4.Admission-Request | | |
| <Flow, | | |
| Customer-Port-ID> | | |
|<--------------------| | |
5.| | | |
+=================+ | | |
[Subscriber B/W ] | | |
[& OLT link B/W ] | | |
[Admission Ctrl ] | | |
+=================+PASS | | |
|6.Admission-Reply-Pass | |
|<Flow,Customer-Port-ID> | |
|-------------------->| | |
| 7.+========================+ | |
| [Update Replication State] | |
| +========================+ | |
| | 8.Admission-Reply-Pass | |
| |(<Flow,Cust-Port-ID> | |
| |----------------------> | |
| | 9.+============+ |
| | [Update Repl.] |
| | [ State ] |
| | +============+ |
Figure 9: Interaction between NAS & ANX for Multicast Bandwidth
Admission Control in the All-ANCP ANX Control Model upon Success
Bitar, et al. Informational [Page 27]
RFC 6934 ANCP in PON-Based Networks June 2013
+----+
+--------- |ONT |------ HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->|OLT | + +-----+
+----+ ANCP | | ANCP +----------| ONU |----- HGW
| +----+<----------------->+-----+------HGW
| | | |
|1.IGMP join(S/*,G) +=============+ +=============+ |
|<------------------[IGMP Snooping]--------[IGMP snooping]-- |
| +=============+ +=============+ |
| |2.Admission-Request | |
| |(Flow,Customer-Port-ID) | |
| |<---------------------- | |
| 2.+===============+ | |
| [ Access Ctrl ] | |
| [ & PON B/W ] | |
| [ Admission Ctrl] | |
| +===============+ PASS | |
|3.Admission-Request | | |
| <Flow,Customer-Port-ID> | |
|<--------------------| | |
4.| | | |
+==================+ | | |
[Subscriber B/W ] | | |
[& OLT link B/W ] | | |
[Admission Ctrl ] | | |
+==================+FAIL | |
| | | |
|5.Admission-Reply-Fail | |
|<Flow,Cust-Port-ID> | | |
|-------------------->| | |
| 6.+==================+ | |
| [Release PON B/W ] | |
| [Remove Repl.State ] | |
| +==================+ | |
| | 7.Admission-Reply-Fail | |
| |<Flow,Cust-Port-ID> | |
| |----------------------> | |
| | 8.+============+ |
| | [Remove Repl.] |
| | [ State ] |
| | +============+ |
Figure 10: Interaction between NAS and ANX for Multicast Bandwidth
Admission Control in the All-ANCP ANX Control Model upon Failure
Bitar, et al. Informational [Page 28]
RFC 6934 ANCP in PON-Based Networks June 2013
+------------+ 1. VoD Request
| App. Server|<-----------------------------------------------
| Server |
+------------+
| 2. Admission-Request (VoD-Flow)
+-------+
|Policy |
|Server |
+-------+
| +
|<-|---3. Admission-Request
| |
+ | 8. Admission-Reply
+----+ + +----+ +-----+
|NAS |---------------|OLT |------<PON>-------|ONT |---HGW--CPE
| |<------------->| | +-----+ |
+----+ ANCP +----+ | |
| | | |
4.| | | |
+=================+ | | |
[Subscriber B/W ] | | |
[& OLT link B/W ] | | |
[Admission Ctrl ] | | |
+=================+PASS | | |
| | | |
| 5.Admission-Request | | |
|(Bandwidth,PON-Port-ID) | |
|-------------------> | | |
| | | |
| 6.+===============+ | |
| [ PON B/W ] | |
| [ Admission Ctrl] | |
| +===============+ PASS | |
|7.Admission-Reply | | |
| <PON-Port-ID> | | |
|<------------------- | | |
| | | |
Figure 11: Interactions for VoD Bandwidth Admission Control
in the All-ANCP ANX Control Model
A third possible approach is where the ANX is assumed to have full
knowledge to make an autonomous decision on admitting or rejecting a
multicast and a unicast join. With respect to the interaction
between ONT/ONU and OLT, the procedure is similar to the first
approach (i.e., NAS-controlled replication). However, when the OLT
receives an IGMP request from a subscriber, it performs admission
control against that subscriber multicast video bandwidth (dedicated
Bitar, et al. Informational [Page 29]
RFC 6934 ANCP in PON-Based Networks June 2013
and shared with Video on Demand), the PON, and uplink to the NAS. It
should be noted in this case that if there are multiple NAS-OLT
links, either the link on which the multicast stream must be sent is
pre-determined, needs to be selected by the OLT based on downstream
bandwidth from NAS to OLT and the selection is communicated to the
NAS, or the OLT has to be ready to receive the stream on any link.
If the check passes, the OLT updates the available video bandwidth
per PON and subscriber. The OLT adds the subscriber to the list of
receivers and the PON to the multicast tree if it is not already on
it. It also sends an ANCP request to the ONT/ONU to add the
subscriber Access Port to that channel multicast tree and sends an
ANCP message to the NAS informing it of the subscriber and link
available video bandwidth and the channel the subscriber joined. The
NAS, upon receiving the ANCP information message, updates the
necessary information, including the OLT to the multicast tree if it
is not already on it. It should be noted in this case that the ANCP
message from the OLT to the NAS is being used to add the OLT to a
multicast tree as opposed to an IGMP message. The IGMP message can
also be sent by the OLT with the OLT acting as an IGMP proxy at the
expense of added messages. In this option, the OLT acts as the
network IGMP router for the subscriber.
For unicast video streams, the policy server receiving an admission
request from an application server, as described before, may query
the OLT for admission control as it has all information. If the OLT
has sufficient bandwidth for the stream, it reserves that bandwidth
for the subscriber, the PON, and OLT uplink to the NAS and returns an
accept to the policy server. It also updates the NAS (via an ANCP
message) of the subscriber's available video bandwidth. If the OLT
rejects the policy server request, it will return a reject to the
policy server.
It should be noted that if the policy server adjacency is with the
NAS, the policy server may make the admission request to the NAS.
The NAS then sends an ANCP admission request to the OLT on behalf of
the policy server. The NAS returns an accept or reject to the policy
server if it gets a reject or accept, respectively, from the OLT.
6.3. Multicast Accounting
It may be desirable to perform accurate time- or volume-based
accounting per user or per access loop. If the ANX is performing the
traffic replication process, it knows when replication of a multicast
flow to a particular Access Port or user starts and stops. Multicast
accounting can be addressed in two ways:
Bitar, et al. Informational [Page 30]
RFC 6934 ANCP in PON-Based Networks June 2013
- ANX keeps track of when replication starts or stops and reports
this information to the NAS for further processing. In this case,
ANCP can be used to send the information from the ANX to the NAS.
This can be done with the Information Report message. The NAS can
then generate the appropriate time and/or volume accounting
information per access loop and per multicast flow to be sent to
the accounting system. The ANCP requirements to support this
approach are specified in [RFC5851]. If the replication function
is distributed between the OLT and ONT/ONU, a query from the NAS
will result in OLT generating a query to the ONT/ONU.
- ANX keeps track of when replication starts or stops and generates
the time- and/or volume-based accounting information per access
loop and per multicast flow, before sending it to a central
accounting system for logging. Since ANX communicates with this
accounting system directly, the approach does not require the use
of ANCP. It is therefore beyond the scope of this document. It
may also be desirable for the NAS to have the capability to
asynchronously query the ANX to obtain an instantaneous status
report related to multicast flows currently replicated by the ANX.
Such a reporting functionality could be useful for troubleshooting
and monitoring purposes. If the replication function in the ANX
is distributed between the OLT and the ONT/ONU, then for some of
the information required by the NAS (such as the list of Access
Ports on which a flow is being forwarded or list of flows being
forwarded on an Access Port), a query to the OLT from the NAS will
result in a query from the OLT to the ONT/ONU. The OLT responds
back to the NAS when it receives the response from the ONT/ONU.
Also, if the list of PONs on which replication is happening for a
multicast channel or the list of channels being replicated on a
PON is what is desired, the OLT can return this information.
7. Remote Connectivity Check
In an end-to-end Ethernet aggregation network, end-to-end Ethernet
Operations, Administration, and Maintenance (OAM), as specified in
IEEE 802.1ag [802.1ag] and ITU-T Recommendation Y.1730/1731 [Y.1731],
can provide access loop connectivity testing and fault isolation.
However, most HGWs do not yet support these standard Ethernet OAM
procedures. Also, in a mixed Ethernet and ATM access network (e.g.,
Ethernet-based aggregation upstream from the OLT and BPON
downstream), interworking functions for end-to-end OAM are not yet
standardized or widely available. Until such mechanisms become
standardized and widely available, the Access Node Control Mechanism
between NAS and ANX can be used to provide a simple mechanism to test
connectivity of an access loop from the NAS.
Bitar, et al. Informational [Page 31]
RFC 6934 ANCP in PON-Based Networks June 2013
Triggered by a local management interface, the NAS can use the Access
Node Control Mechanism (Control Request message) to initiate an
access loop test between an Access Node and a HGW or ONT/ONU. On
reception of the ANCP message, the OLT can trigger native OAM
procedures defined for BPON in [G.983.1] and for GPON in [G.984.1].
The Access Node can send the result of the test to the NAS via a
Control Response message.
8. Access Topology Discovery
In order to avoid congestion in the network, manage and utilize the
network resources better, and ensure subscriber fairness, NAS
performs hierarchical shaping and scheduling of the traffic by
modeling different congestion points in the network (such as the last
mile, Access Node uplink, and the access-facing port).
Such mechanisms require that the NAS gains knowledge about the
topology of the access network, the various links being used, and
their respective rates. Some of the information required is somewhat
dynamic in nature (e.g., DSL line rate if the last mile is xDSL
based, such as in the case of "PON-fed DSLAMs" for FTTC/FTTB
scenarios) and hence cannot come from a provisioning and/or inventory
management Operations Support System (OSS). Some of the information
varies less frequently (e.g., capacity of the OLT uplink) but
nevertheless needs to be kept strictly in sync between the actual
capacity of the uplink and the image the NAS has of it.
OSSs are rarely able to enforce the consistency of such data in a
reliable and scalable manner, notably across organizational
boundaries under certain deployment scenarios. The Access Topology
Discovery function allows the NAS to perform these advanced functions
without having to depend on an error-prone and possibly complex
integration with an OSS.
The rate of the access loop can be communicated via ANCP (Information
Report message) from the ONT/ONU to the OLT in the All-ANCP ANX
control model or via OMCI in the ANCP+OMCI ANX control model, and
then from OLT to the NAS via ANCP. Additionally, during the time the
DSL NT is active, data rate changes can occur due to environmental
conditions (the DSL access loop can get "out of sync" and can retrain
to a lower value, or the DSL access loop could use Seamless Rate
Adaptation to make the actual data rate fluctuate while the line is
active). In this case, ANX sends an additional Information Report to
the NAS each time the access loop attributes change above a threshold
value. Existing DSL procedures are not applicable in this case
because an adapted message flow and additional TLVs are needed.
Bitar, et al. Informational [Page 32]
RFC 6934 ANCP in PON-Based Networks June 2013
+--------+
| Policy |
| Server |
+--------+ +---+ +---+
| +-----------|ONT|---|HGW|
| | +---+ +---+
| +--------------- |-----------------+
+----+ | +----+ | +-----+ | +---+
|NAS |------------ | | | | | |-|-|HGW|
| |<----------> | | | | |ONT/ | | +---+
+----+ ANCP | |OLT |------<PON>--------|ONU | |
| | | | | | | +---+
| | | |<----------------->| |---|HGW|
| | +----+ OMCI +-----+ | +---+
| +----------------------------------+
| | Access Node |
| | |
| |------GPON Ranging------|
| Port Status Message| ONT Port UP |
|<------------------ |<-----------------------|
|Port Configuration GPON Line/Service Profile|
|------------------> |<---------------------->|
| ONT/ONI Port UP| |
|<------------------ | |
| | |
| ANCP | OMCI |
<-------------------><----------------------->|
PPP, DHCP, IP
<------------------------------------------------------>
Figure 12: Message Flow for the Use Case of Topology Discovery for
the ANCP+OMCI Control Model
Figure 12 depicts a message flow for topology discovery when using
the ANCP+OMCI control model. Basically, when an ONT/ONU gets
connected to a PON, the OLT detects a new device and a GPON Ranging
process starts. During this process, the ONT/ONU becomes authorized
by the OLT and identified by ONT/ONU ID, PON Port ID, and max
Bandwidth. This port status is reported via ANCP to the NAS and then
potentially the policy server via another mechanism that is out of
scope of this document. In a second step, after the GPON service
profile is assigned from OLT to ONT/ONU, the OLT reports the final
status to NAS with information about the service profile and other
information such as the ONT/ONU port rate to the subscriber, for
instance.
Bitar, et al. Informational [Page 33]
RFC 6934 ANCP in PON-Based Networks June 2013
9. Access Loop Configuration
Topology Discovery provides Access Port Identification to the NAS
when sending an Access Port Discovery message. This informs NAS
identification of a PON port on an Access Node. Based on Access Port
Identification and on customer identification, service-related
parameters could be configured on an OLT and an ONU/ONT.
Service-related parameters could be sent to OLT via ANCP before or
after an ONU/ONT is up. Sending of ANCP loop configuration messages
from NAS can be triggered by a management system or by customer
identification and authentication after Topology Discovery. It may
be used for first-time configuration (zero touch) or for
updating/upgrading customer's profile like C-VLAN ID, S-VLAN ID, and
service bandwidth.
Parameters of the User-Network Interface (UNI), which is the
subscriber interface to HGW/CPE of ONU/ONT, can also be configured
via ANCP. When the ONU/ONT supports ANCP, parameters of the UNI on
ONU/ONT are sent to the ONU/ONT via ANCP. If the ONU/ONT does not
support ANCP but only OMCI, parameters have to be sent from the NAS
to the OLT via ANCP first. Then, the OLT translates such
configuration into OMCI and sends it to the ONU/ONT.
10. Security Considerations
[RFC5713] lists the ANCP-related security threats that could be
encountered on the Access Node and the NAS. It develops a threat
model for ANCP security and lists the security functions that are
required at the ANCP level.
With multicast handling as described in this document, ANCP protocol
activity between the ANX and the NAS is triggered by join/leave
requests coming from the end-user equipment. This could potentially
be used for a denial-of-service attack against the ANX and/or the
NAS.
To mitigate this risk, the NAS and ANX may implement control plane
protection mechanisms such as limiting the number of multicast flows
a given user can simultaneously join or limiting the maximum rate of
join/leave from a given user.
Protection against invalid or unsubscribed flows can be deployed via
provisioning black lists as close to the subscriber as possible
(e.g., in the ONT).
Bitar, et al. Informational [Page 34]
RFC 6934 ANCP in PON-Based Networks June 2013
User activity logging for accounting or tracking purposes could raise
privacy concerns if not appropriately protected. To protect such
information, logging/accounting information can be exchanged with the
corresponding server over a secure channel, and the information can
be stored securely with policy-driven controlled access.
11. Differences in ANCP Applicability between DSL and PON
As it currently stands, both ANCP framework [RFC5851] and protocol
[RFC6320] are defined in the context of DSL access. Due to inherent
differences between PON and DSL access technologies, ANCP needs a few
extensions for supporting the use cases outlined in this document for
PON-based access. These specific differences and extensions are
outlined below.
- In PON, the access-node functionality is split between OLT and
ONT. Therefore, ANCP interaction between NAS and AN translates to
transactions between NAS and OLT and between OLT and ONT. The
processing of ANCP messages (e.g., for multicast replication
control) on the OLT can trigger generation of ANCP messages from
OLT to ONT. Similarly, ANCP messages from ONT to the OLT can
trigger ANCP exchange between the OLT and the NAS (e.g., admission
request messages). This is illustrated in the generic message
flows in Figures 5 and 6 of Section 5. In the case of DSL, the
ANCP exchange is contained between two network elements (NAS and
the DSLAM).
- The PON connection to the ONT is a shared medium between multiple
ONTs on the same PON. In the case of DSL, the local loop is
point-to-point. In the case of a DSL access network, the access-
facing port on the NAS (i.e., port to the network between NAS and
the DSLAM) and the access-facing ports on the DSLAM (i.e.,
customer's local loop) are the two bandwidth constraint points
that need to be considered for performing bandwidth-based
admission control for multicast video and VoD delivered to the
customer. In the case of PON access, in addition to the bandwidth
constraint on the NAS to OLT facing ports and the subscriber-
allocated bandwidth for video services, the bandwidth available on
the PON for video is an additional constraint that needs to be
considered for bandwidth-based admission control. If the
bandwidth control is centralized in the NAS (as described in the
first approach in Section 6.2), then the NAS needs to support
additional logic to consider available PON bandwidth before
admitting a multicast request or a VoD request by the user.
Accordingly, ANCP needs to identify the customer Access Port and
the PON on which the customer ONT is. If the PON bandwidth
control is performed on the OLT (as defined in the second approach
in Section 6.2), then additional ANCP request and response
Bitar, et al. Informational [Page 35]
RFC 6934 ANCP in PON-Based Networks June 2013
messages are required for NAS to query the OLT to determine
available PON bandwidth when a request to admit a VoD flow is
received on the NAS (as shown in Figure 9 in Section 6.2) or for
the OLT to inform the NAS what stream bandwidth is sent to the
subscriber for the NAS to take appropriate action (e.g., bandwidth
adjustment for various types of traffic).
- In PON, the multicast replication can potentially be performed on
three different network elements: (1) on the NAS, (2) on the OLT
for replication to multiple PON ports, and (3) on the ONT/ONU for
replication to multiple customer ports. In the case of DSL, the
replication can potentially be performed on NAS and/or the DSLAM.
Section 6.2 defines options for multicast replication in the case
of PON. In the first option, the multicast replication is done on
the AN but is controlled from NAS via ANCP (based on the reception
of per-customer IGMP messages on the NAS). In this option, the
NAS needs to supply the OLT the set of PON-customer-IDs (as
defined in Section 2) to which the multicast stream needs to be
replicated. The PON-customer-ID identifies the OLT and the PON
ports on the OLT as well as the ONT and the Access Ports on the
ONT where the multicast stream needs to be replicated. Upon
receiving the request to update its multicast replication state,
the OLT must update its replication state with the indicated PON
ports but may also need to interact with the ONT via ANCP to
update the multicast replication state on the ONT with the set of
Access Ports (as indicated by the NAS). In the case of DSL, the
DSLAM only needs to update its own replication state based on the
set of Access Ports indicated by the NAS.
- For reporting purposes, ANCP must enable the NAS to query the OLT
for channels replicated on a PON or a list of PONs and to specific
Access Ports. The latter should trigger the OLT to query the ONT
for a list of channels being replicated on all Access Ports or on
specific Access Ports to the premises. In a DSL case, it is
sufficient to query the DSLAM for a list of channels being
replicated on an Access Port or a list of Access Ports.
12. ANCP versus OMCI between the OLT and ONT/ONU
ONT Management and Control Interface (OMCI) [OMCI] is specified for
in-band ONT management via the OLT. This includes configuring
parameters on the ONT/ONU. Such configuration can include adding an
Access Port on the ONT to a multicast tree and the ONT to a multicast
tree. Thus, OMCI can be a potential replacement for ANCP between the
OLT and ONT/ONU, albeit it may not be a suitable protocol for dynamic
transactions as required for the multicast application.
Bitar, et al. Informational [Page 36]
RFC 6934 ANCP in PON-Based Networks June 2013
If OMCI is selected to be enabled between the OLT and ONT/ONU to
carry the same information elements that would be carried over ANCP,
the OLT must perform the necessary translation between ANCP and OMCI
for replication control messages received via ANCP. OMCI is an
already available control channel, while ANCP requires a TCP/IP stack
on the ONT/ONU that can be used by an ANCP client, and accordingly,
it requires that the ONT/ONU be IP addressable for ANCP. Most
ONTs/ONUs today have a TCP/IP stack used by certain applications
(e.g., VoIP and IGMP snooping). ANCP may use the same IP address
that is often assigned for VoIP or, depending on the implementation,
may require a different address. Sharing the same IP address between
VoIP and ANCP may have other network implications on how the VoIP
agent is addressed and on traffic routing. For instance, the VoIP
traffic to/from the ONT is often encapsulated in a VLAN-tagged
Ethernet frame and switched at Layer 2 through the OLT to the NAS
where it is routed. The VoIP agent in this case looks like another
subscriber to the NAS. On the other hand, the ANCP session between
the ONT and OLT is terminated at the OLT. Thus, the OLT must be able
to receive/send IP traffic to/from the OLT, which will not work using
this setting. Using a separate IP address for the purpose of ONT/ONU
management or ANCP specifically may often be required when supporting
ANCP. These considerations may favor OMCI in certain environments.
However, OMCI will not allow some of the transactions required in
approach 2, where the ONT/ONU sends unsolicited requests to the OLT
rather than being queried or configured by OLT requests.
13. Acknowledgements
The authors thank Rajesh Yadav and Francois Le Faucheur for their
valuable comments and discussions.
14. References
14.1. Normative References
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
Bitar, et al. Informational [Page 37]
RFC 6934 ANCP in PON-Based Networks June 2013
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
14.2. Informative References
[802.1ag] IEEE 802.1ag, "Connectivity Fault Management", December
2007.
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model", RFC
2881, July 2000.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
RFC 5851, May 2010.
[G.983.1] ITU-T G.983.1, "Broadband optical access systems based on
Passive Optical Networks (PON)", January 2005.
[G.984.1] ITU-T G.984.1, "Gigabit-capable Passive Optical Networks
(GPON): General characteristics", March 2008.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
Aggregation", DSL Forum TR-101, May 2006.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, January 2010.
[OMCI] ITU-T G.984.4, "Gigabit-capable passive optical networks
(G-PON): ONT management and control interface
specification", February 2008.
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
Taylor, Ed., "Protocol for Access Node Control Mechanism
in Broadband Networks", RFC 6320, October 2011.
[G.987.3] ITU-T G.987.3, "10-Gigabit-capable passive optical
networks(XG-PON): Transmission convergence (TC) layer
specification", October 2010.
Bitar, et al. Informational [Page 38]
RFC 6934 ANCP in PON-Based Networks June 2013
[Y.1731] ITU-T Y.1731, "OAM functions and mechanisms for Ethernet
based networks", May 2006.
Authors' Addresses
Nabil Bitar (editor)
Verizon
60 Sylvan Road
Waltham, MA 02451
EMail: nabil.n.bitar@verizon.com
Sanjay Wadhwa (editor)
Alcatel-Lucent
701 East Middlefield Road
Mountain View, CA, 94043
EMail: sanjay.wadhwa@alcatel-lucent.com
Thomas Haag
Deutsche Telekom
EMail: HaagT@telekom.de
Hongyu Li
Huawei Technologies
EMail: hongyu.lihongyu@huawei.com
Bitar, et al. Informational [Page 39]