ANCP R. Maglione
Internet-Draft A. Garofalo
Intended status: Standards Track Telecom Italia
Expires: January 12, 2009 F. Le Faucheur
T. Eckert
Cisco
T. Taylor
Huawei
July 11, 2008
ANCP Multicast Handling Sessions
draft-maglione-ancp-mcast-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2009.
Maglione, et al. Expires January 12, 2009 [Page 1]
Internet-Draft ANCP Multicast Handling July 2008
Abstract
This memorandum aims at presenting ANCP Multicast handling. It
proposes updated description of the Multicast Use cases and
corresponding updated ANCP requirements. It also presents the
corresponding Message Flows.
Maglione, et al. Expires January 12, 2009 [Page 2]
Internet-Draft ANCP Multicast Handling July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 8
3.1. Conditional Access . . . . . . . . . . . . . . . . . . . . 8
3.2. Multicast Admission Control . . . . . . . . . . . . . . . 9
3.2.1. When not to perform Admission Control for a subset
of flows . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Multicast Admission Control and White Lists . . . . . 12
3.3. Multicast Accounting and Reporting . . . . . . . . . . . . 12
3.4. Spontaneous Admission Response . . . . . . . . . . . . . . 12
4. Multicast Protocol Requirements . . . . . . . . . . . . . . . 13
4.1. ANCP Multicast Requirements . . . . . . . . . . . . . . . 13
4.2. ANCP Access Node Multicast Requirements . . . . . . . . . 13
4.3. ANCP NAS Multicast Requirements . . . . . . . . . . . . . 15
5. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Multicast Conditional Access without CAC . . . . . . . . . 17
5.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 17
5.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 18
5.1.3. Join & Leave Operations . . . . . . . . . . . . . . . 18
5.2. Multicast Conditional Access and CAC without AN
Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 20
5.2.1. List/Profile Provisioning . . . . . . . . . . . . . . 20
5.2.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 20
5.2.3. Join & Leave Operations . . . . . . . . . . . . . . . 20
5.3. Multicast Admission Control with AN Bandwidth
Delegation . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.1. List/Profile Provisioning . . . . . . . . . . . . . . 21
5.3.2. Profile Mapping and Initial Bandwidth Delegation . . . 22
5.3.3. Join & Leave Operations . . . . . . . . . . . . . . . 23
5.3.4. AN-Triggered Increase of Delegated Multicast
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 25
5.3.5. NAS-Triggered Decrease of Delegated Multicast
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 26
5.3.6. AN Release of Redundant Multicast Bandwidth . . . . . 26
5.4. Multicast Accounting . . . . . . . . . . . . . . . . . . . 27
5.4.1. List/Profile Provisioning . . . . . . . . . . . . . . 27
5.4.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 28
5.4.3. Join & Leave Operations . . . . . . . . . . . . . . . 28
5.5. Multicast Reporting . . . . . . . . . . . . . . . . . . . 30
5.6. NAS-Controlled Multicast Replication . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . . 35
Maglione, et al. Expires January 12, 2009 [Page 3]
Internet-Draft ANCP Multicast Handling July 2008
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 38
Maglione, et al. Expires January 12, 2009 [Page 4]
Internet-Draft ANCP Multicast Handling July 2008
1. Introduction
[I-D.ietf-ancp-framework] defines a framework and requirements for an
Access Node Control Mechanism between a Network Access Server (NAS)
and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer
(DSLAM)) in a multi-service reference architecture in order to
perform QoS-related, service-related and Subscriber-related
operations. [I-D.ietf-ancp-protocol] specifies a Protocol for Access
Node Control Mechanism in Broadband Networks in line with this
framework.
[I-D.ietf-ancp-framework] defines multicast use cases (in section
3.4) as well as the corresponding ANCP Multicast requirements, ANCP
Access Node Multicast Requirements and ANCP NAS Multicast
Requirements (respectively in sections 4.2, 4.7.7 and 4.8.6). The
multicast use cases addressed are "Conditional Access", "Admission
Control", "Accounting and Reporting", and finally "Spontaneous
Admission Response". The ANCP requirements associated with the
Admission Control use case support a number of models. One such
model is where ANCP allows Admission Control to be performed without
involvement of the Access Node i.e performed by the NAS (possibly
with interactions with a Policy Server). Another model is where
Admission Control is to be performed with some involvement of the
Access Node i.e. performed by NAS (possibly with interactions with a
Policy Server) but this time with some delegation of decision to the
Access Node.
This memorandum proposes some enhancements to the ANCP operations for
the model where some admission control decision is delegated to the
Access Node. The key enhancement is to explicitely delegate
multicast bandwidth to the Access Node for the purpose of multicast
admission control (instead of simply identifying multicast flows that
share the same admission control rules and access control rules, as
per current version of[I-D.ietf-ancp-framework]). This allows the
Access Node to perform admission control without ANCP signaling with
the NAS in more situations than the current proposal.
With this bandwidth delegation approach the AN manages a delegated
multicast bandwidth that is a subset of the total video bandwidth for
an AN port. The AN can autonomously perform admission control of
multicast flows within this delegated bandwidth. An initial value
for the delegated multicast bandwidth can be provisioned on the AN by
the NAS through ANCP. The AN and NAS then communicate via ANCP to
increase or decrease the delegated multicast bandwidth depending on
the relative demand of muticast flows versus unicast flows. The
proposed approach for admission control with bandwidth delegation is
compatible with all the conditional access methods supported by
[I-D.ietf-ancp-framework]. In particular, it allows multicast
Maglione, et al. Expires January 12, 2009 [Page 5]
Internet-Draft ANCP Multicast Handling July 2008
admission control check to be performed by the AN even when the AN
needs to query the NAS for conditional access check.
This memorandum identifies all the corresponding changes that would
be required to [I-D.ietf-ancp-framework] in order to reflect the
proposed multicast admission control enhancement. The corresponding
message flows are also documented, in view of clarifying all the
proposed multicast ANCP operations and facilitating future
specification of the corresponding ANCP protocol extensions.
This memorandum does not propose any change to the other model of
operations for multicast Admission Control Control, nor to ANCP
operations for the other multicast use cases.
Maglione, et al. Expires January 12, 2009 [Page 6]
Internet-Draft ANCP Multicast Handling July 2008
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Maglione, et al. Expires January 12, 2009 [Page 7]
Internet-Draft ANCP Multicast Handling July 2008
3. Multicast Use Cases
This section describes the ANCP use cases related to Multicast.
3.1. Conditional Access
This section discusses the changes proposed to section 3.4.1 of
[I-D.ietf-ancp-framework].
[I-D.ietf-ancp-framework] defines the concept of multicast flows that
share the same control rules (ie same Conditional Access rules and
same Admission Control rules). The objective of this concept was to
achieve a tradeoff between pre-provisioning the AN with all
Conditional Access and Admission Control information and querying the
NAS on a per join basis. The former may be a configuration burden
and may lead in large delays when the NAS or AN restarts, while the
latter may increase channel join and channel change times because of
the additional message processing involved in the AN, the NAS and
potentially the Policy Server.
Now considering that
o this memorandum proposes (in Section 3.2) the extension of the
concept of multicast flows that share the same Admission Control
rules into an approach of bandwidth delegation from NAS to the AN
whereby channels of equivalent bandwidth no longer need to be
provisioned into the AN by the NAS
o grey lists in case of the Conditional Access scenario are mainly
used in order to be able to have the conditional access decision
taken by the NAS or a Policy Server (especially in order to
address the case when conditional access information changes
frequently, or when the multicast groups are not known to a client
application in advance, thus where it may not be possible or
convenient to pre-provisioning AN with conditional access
information)
we propose to simplify operations of Conditional Access and remove
the notion of multicast flows sharing the same conditional access
rules. Specifically, we propose to remove the following two
paragraphs of section 3.4.1 [I-D.ietf-ancp-framework]:
"Querying the NAS before performing a join on the AN may increase
channel join and channel change times because of the additional
message processing involved in the AN, the NAS and potentially the
Policy Server. On the other hand, pre-provisioning per subscriber
profiles potentially different for each subscriber may be a
configuration burden, may result in large delays when the NAS or AN
Maglione, et al. Expires January 12, 2009 [Page 8]
Internet-Draft ANCP Multicast Handling July 2008
restarts, or may not be viable when conditional access changes
frequently or are to remain under the control of an external
administrative entity.
In order to account for these operational factors and associated
trade-offs, in some cases, the provisioning and querying techniques
can be combined. In such a model, the AN sends an Admission Request
message to the NAS as a trigger for a particular multicast flow. The
NAS would then send back an Admission Response message to the AN,
including conditional access information for that multicast flow, as
well as for a set of multicast flows sharing the same conditional
access rules. The AN can then autonomously honor or deny requests
for a given user/port for the set of Multicast flows as indicated in
the Admission Response message."
3.2. Multicast Admission Control
Section 3.4.2 of [I-D.ietf-ancp-framework] presents the requirement
for synchronization between the entity performing multicast CAC, the
entity performing unicast CAC and the entity actually enforcing
multicast replication. It describes three approaches to perform this
synchronization. This memorandum proposes the following changes to
the methods described in the first and in the third bullet.
Replace the following text:
" One approach is for the AN to query the NAS so that both unicast
and multicast CAC for the access line are performed by the NAS. In
this case, the AN can use ANCP to query the NAS, that in turn
performs multicast CAC and responds to the AN indicating whether the
join is to be honored (and hence replication performed by the AN) or
denied. The NAS may locally maintain available "video" bandwidth on
the Access Loop, and perform video bandwidth accounting for the
Access Loop. Upon receiving an Admission Request from the AN, the
NAS can check available "video" bandwidth before admitting or denying
the multicast flow. In the process, the NAS may communicate with the
Policy Server. For unicast video services such as Video on Demand
(VoD), the NAS may also be queried (by a Policy Server or via on-path
CAC signaling), so that it can perform admission control for the
unicast flow, and update the available video bandwidth maintained by
the NAS. Similarly to what has been discussed in the Conditional
Access use case, in response to a Admission Request from the AN for
admission control of a multicast flow, the NAS may send back an
Admission Response message to the AN, including admission control
information for that multicast flow, as well as for a set of
multicast flows sharing the same admission control rules. The AN can
then autonomously honor or deny requests for a given user/port for
the set of Multicast flows as indicated in the Admission Response
Maglione, et al. Expires January 12, 2009 [Page 9]
Internet-Draft ANCP Multicast Handling July 2008
message. The ANCP requirements to support this approach (where the
AN queries the NAS) are specified in this document;"
by the following text:
"One approach is where ANCP allows Admission Control to be performed
by the NAS (possibly with interactions with a Policy Server) either
without any involvement of the Access Node or with some involvement
of the Access Node in particular with the delegation of some
decisions to the Access Node.
The NAS uses ANCP to indicate to the AN whether or not Admission
Control is needed for each multicast flow on a given Access Port, and
where Admission Control is needed whether or not it is to be
performed with AN Bandwidth Delegation. In particular:
o multicast flows that require Admission Control without AN
Bandwidth Delegation are inserted in the Grey List and these
entries are flagged as "no Bandwidth Delegation";
o multicast flows that require Admission Control with AN Bandwidth
Delegation are:
o
* inserted in the White list and flagged as "Bandwidth
Delegation", in case they do not require any Conditional Access
operation to be performed by the NAS
* inserted in the Grey List and flagged as "Bandwidth
Delegation", in case they require some Conditional Access
checks to be performed by the NAS.
In case of Admission Control without AN Bandwidth Delegation, the AN
can use ANCP to query the NAS, that in turn performs multicast
Admission Control check for the new multicast flow and responds to
the AN indicating whether the join is to be honored (and hence
replication performed by the AN) or denied. The NAS may locally
maintain available "video" bandwidth on the Access Loop, and perform
video bandwidth accounting for the Access Loop. Upon receiving an
Admission Request from the AN, the NAS can check available "video"
bandwidth before admitting or denying the multicast flow. In the
process, the NAS may communicate with the Policy Server. For unicast
video services such as Video on Demand (VoD), the NAS may also be
queried (by a Policy Server or via on-path CAC signaling), so that it
can perform admission control for the unicast flow, and update the
available video bandwidth maintained by the NAS.
Maglione, et al. Expires January 12, 2009 [Page 10]
Internet-Draft ANCP Multicast Handling July 2008
In case of Admission Control with AN Bandwidth Delegation, the NAS
(possibly with interactions with a Policy Server) manages total
bandwidth for video admission, performs unicast admission control and
uses ANCP to delegate a certain amount of bandwidth for some
multicast flows to the Access Node. In this scenario upon receiving
a join to a multicast flow which matches the White or Grey Lists
whose entry is flagged as "Bandwidth Delegation" for a specific
Access Port, before starting the multicast flow replication the AN
must perform the necessary bandwidth admission control check for the
new multicast flow.
In some cases, the bandwidth that the NAS initially delegated to the
AN may not be enough to satisfy a multicast request for a new flow.
In this scenario the AN can use ANCP to query the NAS in order to
request additional multicast bandwidth; the NAS (possibly with
interactions with a Policy Server) decides if the request for more
bandwidth can be satisfied and uses ANCP to send a response to the AN
indicating the updated delegated multicast bandwidth. It is worth
noticing that in this case, the time taken to complete the procedure
is an increment to the zapping delay: in order to minimize the
zapping delay for future join requests the AN can insert in the
request message two values: the minimum amount of additional
multicast bandwidth requested, and the preferred additional amount.
The first value is the amount that allows the present join request to
be satisfied, the second value an amount that anticipates further
join requests.
In some cases, the NAS (or the Policy Server) may not have enough
unicast bandwidth to satisfy a new incoming video request: in these
scenarios the NAS can use ANCP to query (or instruct) the AN in order
to decrease the amount of multicast bandwidth previously delegated on
a given Access Port. The AN upon receiving this query from the NAS
can use ANCP to send a response to AN indicating the updated
delegated multicast bandwidth. Actually, based on considerations
similar to those of the previous paragraph, it indicates the minimum
amount of multicast bandwidth that it needs released and a preferred
amount, which may be larger.
In addition in some cases upon receiving a leave for a specific
multicast flow the AN can decides that it has an excess of delegated
but uncommitted bandwidth, thus the AN can use ANCP to send a message
to the NAS to release unused multicast bandwdth previously delegated.
The ANCP requirements to support this approach (where the AN queries
the NAS) are specified in this document; "
Replace this text:
Maglione, et al. Expires January 12, 2009 [Page 11]
Internet-Draft ANCP Multicast Handling July 2008
" In a third approach, the Policy Server queries the AN (either
directly, or indirectly via the NAS) so that both unicast and
multicast CAC for the access line are performed by the AN. In this
case, a subscriber request for a unicast flow (e.g. a Video on Demand
session) will trigger a resource request message towards a Policy
Server; the latter will then query the AN, that in turn will perform
unicast CAC for the access line and respond, indicating whether the
unicast request is to be honored or denied. This method will not be
addressed in this document; it may be covered by means of ANCP
extensions at a later stage. "
by the following text:
"In a third approach, the Policy Server queries the AN directly so
that both unicast and multicast CAC for the access line are performed
by the AN. In this case, a subscriber request for a unicast flow
(e.g. a Video on Demand session) will trigger a resource request
message towards a Policy Server; the latter will then query the AN,
that in turn will perform unicast CAC for the access line and
respond, indicating whether the unicast request is to be honored or
denied. In this scenario the Policy Server queries the AN directly,
the approach doesn't require the use of ANCP. It is therefore beyond
the scope of this document."
3.2.1. When not to perform Admission Control for a subset of flows
This memorandum does not propose any update over the description of
this use case provided in section 3.4.2.1 of
[I-D.ietf-ancp-framework].
3.2.2. Multicast Admission Control and White Lists
This memorandum does not propose any update over the description of
this use case provided in section 3.4.2.2 of
[I-D.ietf-ancp-framework].
3.3. Multicast Accounting and Reporting
This memorandum does not propose any update over the description of
this use case provided in section 3.4.3 of [I-D.ietf-ancp-framework].
3.4. Spontaneous Admission Response
This memorandum does not propose any update over the description of
this use case provided in section 3.4.4 of [I-D.ietf-ancp-framework].
Maglione, et al. Expires January 12, 2009 [Page 12]
Internet-Draft ANCP Multicast Handling July 2008
4. Multicast Protocol Requirements
4.1. ANCP Multicast Requirements
This memorandum proposes the following changes to section 4.2 of
[I-D.ietf-ancp-framework].
Replace the following requirement:
o The ANCP must allow the NAS, when replying to an AN request, to
convey information on multiple multicast flows sharing the same
conditional access and/or admission control rules. This allows
the AN to take autonomous decisions for these flows later on.
by the following requirements:
o The ANCP must allow the NAS to indicate to the AN whether or not
Admission Control is needed for some multicast flows on a given
Access Port and where needed whether or not it is to be performed
with AN Bandwidth Delegation.
o In case of Admission Control without AN Bandwidth Delegation the
ANCP must allow the NAS to reply to a query from the AN indicating
whether or not a multicast flow may be replicated to a particular
Access Port.
o In case of Admission Control with AN Bandwidth Delegation, the
ANCP must allow the NAS to delegate a certain amount of bandwidth
to the AN for a given Access Port.
o In case of Admission Control with AN Bandwidth Delegation the ANCP
must allow the AN to query the NAS to request additional multicast
bandwidth on a given Access Port.
o In case of Admission Control with AN Bandwidth Delegation the ANCP
must allow the NAS to query (or to instruct) the AN to reduce the
amount of bandwidth previously delegated on a given Access Port.
o In case of Admission Control with AN Bandwidth Delegation the ANCP
must allow the AN to autonomous release redundant multicast
bandwidth on a given Access Port.
4.2. ANCP Access Node Multicast Requirements
This memorandum proposes the following changes to section 4.7.6 of
[I-D.ietf-ancp-framework].
Replace the following requirements:
Maglione, et al. Expires January 12, 2009 [Page 13]
Internet-Draft ANCP Multicast Handling July 2008
o The AN must accept any join to a multicast flow matching the White
List for the relevant Access Port.
o Upon receiving a join to a multicast flow which matches the Grey
List for a specific Access Port, the AN must support using ANCP to
query the NAS to receive a response indicating whether that join
is to be honored or denied.
o Upon querying the NAS, the AN should support receiving ANCP
messages from the NAS containing conditional access and/or
admission control information of multiple multicast flows. This
allows the AN to take autonomous decisions for these flows later
on.
o The AN should support using ANCP to notify the NAS when resources
for a multicast flow are no longer in use (e.g. the AN is no
longer replicating any multicast flows from a set of multicast
flows sharing the same admission control rules). This allows
corresponding bandwidth to be released on NAS.
by the following requirements:
o The AN must accept any join to a multicast flow matching the White
List and flagged as "no CAC" for the relevant Access Port.
o Upon receiving a join to a multicast flow which matches the White
List whose entry is flagged as "Bandwidth Delegation" for a
specific Access Port, before starting the multicast flow
replication the AN must perform the necessary bandwidth admission
control check for the new flow.
o Upon receiving a join to a multicast flow which matches the Grey
List whose entry is flagged as "no Bandwidth Delegation" for a
specific Access Port, the AN must support using ANCP to query the
NAS that in turn will perform both the necessary conditional
access and the admission control checks for the new flow and sends
a response indicating whether that join is to be honored or
denied. The AN must support using ANCP to notify the NAS when the
the user leaves the multicast flow.
o Upon receiving a join to a multicast flow which matches the Grey
List whose entry is flagged as "Bandwidth Delegation" for a
specific Access Port, the AN must perform the necessary bandwidth
admission control check for the new flow and if it is successful
the AN must support using ANCP to query the NAS to receive a
response indicating whether that join is to be honored or denied.
Maglione, et al. Expires January 12, 2009 [Page 14]
Internet-Draft ANCP Multicast Handling July 2008
o In case of Admission Control with AN Bandwidth Delegation, the AN
must support using ANCP to query the NAS to request additional
delegated multicast bandwidth on a given Access Port; the AN
should be able to specify both the minimum and the preferred
amount of additional multicast bandwidth requested.
o In case of Admission Control with AN Bandwidth Delegation, upon
receiving a Bandwidth Delegation Request from the NAS querying or
instructing to decrease the delegated multicast bandwidth on a
given Access Port, the AN must support using ANCP to send a
Bandwidth Delegation Response indicating the new delegating
multicast bandwidth
o In case of Admission Control with AN Bandwidth Delegation, the AN
must support using ANCP to send a Bandwidth Release message to the
NAS in order to release unused delegated multicast bandwidth on a
given Access Port.
4.3. ANCP NAS Multicast Requirements
This memorandum proposes the following changes to section 4.8.6 of
[I-D.ietf-ancp-framework].
Replace the following requirements:
o The NAS must support using ANCP to configure multicast conditional
access information to Access Ports on an Access Node, using Black
Lists and White Lists
o Upon receiving a query from the AN for a request to replicate a
multicast flow to a particular Access Port, the NAS must support
using ANCP to reply to the AN indicating whether the request is to
be honored or denied.
o Upon receiving a query from the AN for a request to replicate
multicast flow to a particular Access Port, the NAS should support
sending an Admission Response message containing conditional
access and/or admission control information of multiple multicast
flows. This allows the AN to take autonomous decisions for these
flows later on
by the following requirements:
o The NAS must support using ANCP to configure multicast conditional
access information to Access Ports on an Access Node, using Black
Lists, Grey Lists and White Lists.
Maglione, et al. Expires January 12, 2009 [Page 15]
Internet-Draft ANCP Multicast Handling July 2008
o The NAS must support using ANCP to indicate to the AN whether or
not Admission Control is needed for some multicast flows on a
given Access Port and where needed whether or not it is to be
performed with AN Bandwidth Delegation.
o Upon receiving a query from the AN for a request to replicate a
multicast flow to a particular Access Port and where Admission
Control is not needed for that multicast flow on that Access Port,
the NAS must be able to perform the necessary conditional access
check for the new flow and the NAS must support using ANCP to
reply to the AN indicating whether the request is to be honored or
denied.
o Upon receiving a query from the AN for a request to replicate a
multicast flow to a particular Access Port and where Admission
Control without AN Bandwidth Delegation is needed for that
multicast flow on that Access Port, the NAS must be able to
perform both the necessary conditional access (if needed) and the
bandwidth admission control check for the new flow and the NAS
must support using ANCP to reply to the AN indicating whether the
request is to be honored or denied.
o In case of Admission Control with AN Bandwidth Delegation the NAS
must support using ANCP to delegate a certain amount of bandwidth
to the AN for a given Access Port.
o In case of Admission Control with AN Bandwidth Delegation, upon
receiving a Bandwidth Delegation Request from the AN requesting to
increase the delegated multicast bandwidth on a given Access Port,
the NAS must support using ANCP to send a Bandwidth Delegation
Response indicating the new delegating multicast bandwidth.
o In case of Admission Control with AN Bandwidth Delegation, the NAS
must support using ANCP to send a request the AN to decrease the
amount of multicast bandwidth previously delegated on a given
Access Port; the NAS should be able to specify both the minimum
and the preferred amount decrement of multicast bandwidth
requested.
o In case of Admission Control with AN Bandwidth Delegation, upon
receiving an ANCP Bandwidth Release message, the NAS must be able
to update accordingly its view of the multicast bandwidth
delegated to the AN.
Maglione, et al. Expires January 12, 2009 [Page 16]
Internet-Draft ANCP Multicast Handling July 2008
5. Message Flows
This section documents the message flows associated with multicast
handling by ANCP. It is not proposed that these message flows be
incorporated in [I-D.ietf-ancp-framework] since message flows are
outside its scope. These messages flows are intended to clarify
operation of the ANCP Multicast and provide guidance for the
specification of ANCP Protocol extensions for support of multicast.
5.1. Multicast Conditional Access without CAC
This section describes ANCP operations when multicast flows are
subject to multicast Conditional Access but not subject to CAC.
5.1.1. List/Profile Provisioning
The AN provisioning is performed by NAS using a Provisioning message
that contains White/Black/Grey lists and their corresponding
"Multicast Profile ID". To indicate to the AN that it need not
perform any CAC operation on those flows, the White List entries are
flagged as "no CAC" and the Grey List entries are flagged as "no
Bandwidth Delegation". The corresponding message flow is illustrated
in Figure 1.
Although Figure 1 shows the three lists in the ANCP provisioning
message, the message may instead contain any subset of 2 or 1 list.
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | Provisioning( |
| | | (White List(noCAC), |
| | | Grey List(noBD), |
| | | Black List, |
| | | Profile_ID) |
| | |<--------------------|
(noCAC): entries in the White List flagged as "no CAC"
(noBD) : entries in the Grey List flagged
as "no Bandwidth Delegation"
Figure 1: Provisioning AN with White/Grey/Black Lists for Conditional
Access
Maglione, et al. Expires January 12, 2009 [Page 17]
Internet-Draft ANCP Multicast Handling July 2008
5.1.2. Profile Mapping
As soon as the AN port comes up, the AN sends an ANCP PORT_UP message
to the NAS specifying the Access Loop Circuit ID. The NAS replies
with an ANCP PORT_MNGT message that, together with the other
parameters, includes the Multicast Profile ID to be associated to
that Port. The corresponding message flow is illustrated in
Figure 2.
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | |
| | DSL Synch. | |
| |--------------------->| |
| | | PORT_UP(Port ID) |
| | |-------------------->|
| | | (*)
| | | PORT_MNGT(Port ID, |
| | | Profile_ID) |
| | |<--------------------|
(*) The NAS may optionnaly communicate with an external
Autorization/Policy Server
Figure 2: Associating Profile ID to AN Port
5.1.3. Join & Leave Operations
The message flows in Figure 3 illustrates the behavior of the AN in
case of receiving a join and leave messages on the Access Port for
multicast flows respectively part of:
o white list (with matching entry flagged as "no CAC")
o black list
o grey list (with matching entry flagged as "no Bandwidth
Delegation")
Maglione, et al. Expires January 12, 2009 [Page 18]
Internet-Draft ANCP Multicast Handling July 2008
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| | | |
| Join(WhiteNoCAC-Fl) | |
|------------+--------->| |
| | | |
| Mcast White Flow | |
|<======================+ |
| | | |
| | | |
| Leave(WhiteNoCAC-Fl) | |
|------------+--------->| |
| | | |
| Join(Black-Fl) | |
|-----------+---------->x |
| <No Replication > | |
| <For Black-Flow > | |
| | | |
| | | |
| Join(GreyNoBD-Fl) | Admission |
|-----------+---------->| Request |
| | |------------------>|
| | | Admission (*)
| | | Response |
| Mcast Grey Flow |<------------------|
|<======================+ |
| | |
| | | |
| Leave(GreyNoBD-Fl) | Admission |
|-----------+---------->| Release |
| | |------------------>|
| | | |
WhiteNoCAC-Fl : Multicast Flow matching an entry in White List
flagged as "No CAC"
GreyNoBD-Fl : Multicast Flow matching an entry in Grey List
flagged as "No Bandwidth Delegation"
(*) The NAS may optionnaly communicate with an external
Autorization/Policy Server
Figure 3: Multicast Conditional Access
Maglione, et al. Expires January 12, 2009 [Page 19]
Internet-Draft ANCP Multicast Handling July 2008
5.2. Multicast Conditional Access and CAC without AN Bandwidth
Delegation
This section describes ANCP operations when multicast flows are
subject to multicast Conditional Access and subject to CAC on NAS
without bandwidth delegation on the Access Node.
5.2.1. List/Profile Provisioning
The AN provisioning is performed by NAS using a Provisioning message
that contains Black/Grey lists and their corresponding "Multicast
Profile ID". To indicate to the AN that it need not perform any CAC
operation on those flows, the Grey List entries are flagged as "no
Bandwidth Delegation". The corresponding message flow is illustrated
in Figure 4.
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | Provisioning( |
| | | (Grey List(noBD), |
| | | Black List, |
| | | Profile_ID) |
| | |<--------------------|
(noBD) : entries in the Grey List flagged
as "no Bandwidth Delegation"
Figure 4: Provisioning AN with Grey/Black Lists for Conditional
Access and CAC without Bandwidth Delegation
5.2.2. Profile Mapping
The "Profile ID" is associated to the port when the DSL line comes up
in the exact same way as illustrated in Figure 2.
5.2.3. Join & Leave Operations
Upon receiving a join request for a multicast flow in a Grey List
whose entry is flagged as "No Bandwidth Delegation", the AN uses ANCP
to query the NAS, that in turn will perform the necessary conditional
access check and bandwidth admission control check for the new flow
and then it will respond to the AN indicating whether the join is to
be honored (and hence replication performed by the AN) or denied (and
hence replication not performed by the AN). This is illustrated in
Figure 5.
Maglione, et al. Expires January 12, 2009 [Page 20]
Internet-Draft ANCP Multicast Handling July 2008
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| | | |
| Join(Black-Fl) | |
|-----------+---------->x |
| <No Replication > | |
| <For Black-Flow > | |
| | | |
| Join(GreyNoBD-Fl) | Admission |
|-----------+---------->| Request |
| | |------------------>|
| | | (*)
| | | Admission |
| | | Response |
| Mcast-Flow |<------------------|
|<======================+ |
| | | |
| | | |
| Leave(GreyNoBD-Fl) | Admission |
|-----------+---------->| Release |
| | |------------------>|
(*) The NAS may optionnaly communicate with an external
Autorization/Policy Server
Figure 5: Multicast Admission Control without AN Bandwidth Delegation
5.3. Multicast Admission Control with AN Bandwidth Delegation
This section describes ANCP operations when multicast flows are
subject to multicast Conditional Access and subject to CAC on NAS
with bandwidth delegation on the Access Node.
5.3.1. List/Profile Provisioning
The AN provisioning is performed by NAS using a Provisioning message
that contains White/Black/Grey lists and their corresponding
"Multicast Profile ID". To indicate to the AN that it need perform
CAC in compliance with Bandwidth Delegation on those flows, the White
List entries and Grey List Entries are flagged as "Bandwidth
Delegation". The corresponding message flow is illustrated in
Figure 1.
Although Figure 6 shows the three lists in the ANCP provisioning
message, the message may instead contain any subset of 2 or 1 list.
Maglione, et al. Expires January 12, 2009 [Page 21]
Internet-Draft ANCP Multicast Handling July 2008
The AN is configured by other means with the multicast bandwidth
required for each multicast flow.
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | Provisioning( |
| | | (White List(BD), |
| | | Grey List(BD), |
| | | Black List, |
| | | Profile_ID) |
| | |<--------------------|
(BD): entries in the White/Grey List flagged
as "Bandwidth Delegation"
Figure 6: Provisioning AN with White/Grey/Black Lists for Conditional
Access
5.3.2. Profile Mapping and Initial Bandwidth Delegation
The "Profile ID" is associated to the port when the DSL line comes up
in the same way as illustrated in Figure 2. In addition, the NAS
passes to the AN the total video bandwidth (unicast plus multicast)
associated to the AN port and the initial AN allocation of multicast
bandwidth for the port. The message flow combining these two steps
is illustrated in Figure 7.
Maglione, et al. Expires January 12, 2009 [Page 22]
Internet-Draft ANCP Multicast Handling July 2008
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | |
| | DSL Synch. | |
| |--------------------->| |
| | | PORT_UP(Port ID) |
| | |-------------------->|
| | | (*)
| | | PORT_MNGT(Port ID, |
| | | Profile_ID, |
| | | Total Video bw, |
| | | Delegated multicast |
| | | Bandwidth) |
| | |<--------------------|
| | | |
| | | Response |
| | |-------------------->|
| | | |
| | | (*)
| | | |
(*) The NAS may optionnaly communicate with an
external Policy Server
Figure 7: Multicast Admission Control with AN Bandwidth Delegation
5.3.3. Join & Leave Operations
Upon receiving a join request for a multicast flow in a Grey List
whose entry is flagged as "Bandwidth Delegation", the AN performs
admission control of the flow in accordance with Bandwidth Delegation
and uses ANCP to query the NAS that in turn will perform the
necessary conditional access check for the new flow. The NAS will
respond to the AN indicating whether the join is to be honored (and
hence replication performed by the AN) or denied (and hence
replication not performed by the AN). This is illustrated in
Figure 8. In the case where the NAS reponses indicates that the
replication is not to be honored, the AN will reflect this in his
Bandwidth Delegation operation (ie release corresponding bandwidth
within the delegated bandwidth).
Maglione, et al. Expires January 12, 2009 [Page 23]
Internet-Draft ANCP Multicast Handling July 2008
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(WhiteBD-Fl) | |
|-----------+---------->| |
| | | |
| Mcast-Flow | |
|<======================| |
| | | |
| Leave(WhiteBD-Fl) | |
|-----------+---------->| |
| | | |
| | | |
| | | |
| JOIN(Black-Fl) | |
|-----------+---------->| |
| <No Replication > | |
| <For Black-Flow > | |
| | | |
| Join(GreyBD-Fl) | Admission |
|-----------+---------->| Request |
| | |------------------>|
| | | (*)
| | | Admission |
| | | Response |
| Mcast-Flow |<------------------|
|<======================| |
| | | |
| Leave(GreyBD-FL) | Admission |
|-----------+---------->| Release |
| | |------------------>|
WhiteBD-Fl : Multicast Flow matching an entry in White List
flagged as "Bandwidth Delegation"
GreyBD-Fl : Multicast Flow matching an entry in Grey List
flagged as "Bandwidth Delegation"
(*) The NAS may optionnaly communicate with an
external Autorization/Policy Server
Figure 8: Multicast Admission Control with AN Bandwidth Delegation
Maglione, et al. Expires January 12, 2009 [Page 24]
Internet-Draft ANCP Multicast Handling July 2008
5.3.4. AN-Triggered Increase of Delegated Multicast Bandwidth
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(WhiteBD-Fl1) | |
|-----------+---------->| |
| | | |
| Mcast-Flow | |
|<======================| |
| | | |
| Leave(Flow) | |
|-----------+---------->| |
| | | |
| | | |
| Join(WhiteBD-Fl2) | Band Delegation |
|-----------+---------->| Request |
| | | (min increment, |
| | |(pref increment) |
| | |------------------>|
| | | (*)
| | | Band Delegation |
| | | Response |
| | | (delegated |
| | | multicast bw) |
| Mcast-Flow |<------------------|
|<======================| |
| | | |
| Leave(Flow) | |
|-----------+---------->| |
| | | |
WhiteBD-Fl1 : Multicast Flow matching an entry in White List
flagged as "Bandwidth Delegation"
WhiteBD-Fl2 : Multicast Flow matching an entry in White List
flagged as "Bandwidth Delegation"
WhiteBD-Fl2 requires more bandwidth than currently
remaining available from the multicast delegated bandwidth
(*) The NAS may optionnaly communicate with an
external Autorization/Policy Server
Figure 9: Requesting More Multicast Bandwidth
Maglione, et al. Expires January 12, 2009 [Page 25]
Internet-Draft ANCP Multicast Handling July 2008
5.3.5. NAS-Triggered Decrease of Delegated Multicast Bandwidth
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| | | (*)
| | | |
| | | Band Delegation |
| | | Request |
| | | (min increment, |
| | |(pref increment) |
| | |<------------------|
| | | |
| | | Band Delegation |
| | | Response |
| | | (delegated |
| | | multicast bw) |
| | |------------------>|
| | | |
| | | (*)
| | | |
(*) The NAS may optionnaly communicate with an
external Autorization/Policy Server
Figure 10: Requesting More Unicast Bandwidth
5.3.6. AN Release of Redundant Multicast Bandwidth
Maglione, et al. Expires January 12, 2009 [Page 26]
Internet-Draft ANCP Multicast Handling July 2008
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Leave(WhiteBD-Fl) | |
|----------------------->| Band Release |
| | | (allocated multicast|
| | | bandwidth) |
| | |--------------------->|
(*)
WhiteBD-Fl : Multicast Flow matching an entry in White List
flagged as "Bandwidth Delegation"
(*) The NAS may optionnaly communicate with an
external Autorization/Policy Server
Figure 11: AN Autonomous Release of Multicast Bandwidth
5.4. Multicast Accounting
The NAS specifies if accounting is needed for a particular multicast
flow: for Multicast flows belonging to the Grey list this can be
conveyed in the ANCP Admission Response message sent from NAS to AN.
For Multicast flows whose replication is controlled by the AN via the
White list, the AN starts the multicast replication without querying
the NAS and thus the NAS does not send Admission Response message; in
this case the need for accounting is conveyed by the NAS in the White
list during the White list provisioning phase.
5.4.1. List/Profile Provisioning
The AN provisioning is performed by NAS using a Provisioning message
that contains White/Black/Grey lists and their corresponding
"Multicast Profile ID". To indicate to the AN that it need perform
Accounting on those flows, the White List entries are flagged as
either "Basic Accounting" or "Detailed Accounting". The
corresponding message flow is illustrated in Figure 12.
Although Figure 6 shows the three lists in the ANCP provisioning
message, the message may instead contain any subset of 2 or 1 list.
Maglione, et al. Expires January 12, 2009 [Page 27]
Internet-Draft ANCP Multicast Handling July 2008
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | Provisioning( |
| | |(White List (Accounting), |
| | | Grey List, |
| | | Black List, |
| | | Profile_ID) |
| | |<-------------------------|
| | | |
(Accounting): entries in the White List flagged
as "Basic Accounting" or "Detailed Accounting"
Figure 12: Provisioning AN with White/Grey/Black Lists for Accounting
5.4.2. Profile Mapping
The "Profile ID" is associated to the port when the DSL line comes up
in the exact same way as illustrated in Figure 2.
5.4.3. Join & Leave Operations
The message flows in Figure 13 illustrates the behavior of the AN in
case of receiving a join and leave messages on the Access Port for
multicast flows respectively part of:
o white list (with matching entry flagged as "Basic Accounting" or
"Detailed Accouting")
o black list
o grey list
Maglione, et al. Expires January 12, 2009 [Page 28]
Internet-Draft ANCP Multicast Handling July 2008
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| | | |
| Join(WhiteAcct-Fl) | |
|------------+----------->| |
| | | |
| Mcast White Flow | |
|<========================+ Replication Start |
| | |------------------->|
| | | |
| | | |
| | | |
| Leave(WhiteAcct-Fl) | |
|------------+----------->| Information Report |
| | |------------------->|
| | | |
| Join(Black-Fl) | |
|------------+----------->x |
| <No Replication > | |
| <For Black-Flow > | |
| | | |
| | | |
| Join(Grey-Fl) | Admission |
|------------+----------->| Request |
| | |------------------->|
| | | Admission (*)
| | |Response(Accounting)|
| Mcast Grey Flow |<-------------------|
|<========================+ |
| | |
| | | Replication Start |
| | |------------------->|
| Leave(Grey-Fl) | |
|------------+----------->| Information Report |
| | |------------------->|
| | | |
WhiteAcct-Fl : Multicast Flow matching an entry in White List
flagged as "Basic Accouting"
Grey-Fl : Multicast Flow matching an entry in Grey List
(*) The NAS may optionnaly communicate with an external
AAA Server
Maglione, et al. Expires January 12, 2009 [Page 29]
Internet-Draft ANCP Multicast Handling July 2008
Figure 13: Multicast Accounting
5.5. Multicast Reporting
NAS uses "Port Report-Query" to query the AN to know which flows are
currently active on a specific port;
NAS uses "Multicast Flow Report-Query" to query the AN to know on
which ports the specified multicast flow is currently active;
NAS uses "AN global Report-Query" to query the AN to know all
multicast flows currently active on all AN ports.
The message flows in Figure 14 illustrates the behavior of the AN in
case of receiving one of three Report Query messages from the NAS.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| | | Port Report-Query |
| | | (Port ID) |
| Report (Mcast flows) |<------------------|
|------------+----------->| |
| | | |
| | | |
| | | Flow Report-Query |
| | | (Mcast Flow) |
| Report (Port IDi, |<------------------|
| Port IDj,..) | |
|------------+----------->| |
| | | |
| | | |
| | |Global-Report-Query|
| | | (Port ID) |
| | | |
|Report (All Mast Flows) |<------------------|
|------------+----------->| |
Figure 14: Multicast Reporting
5.6. NAS-Controlled Multicast Replication
The Replication Control Request Message is sent by the NAS to the AN
with a directive to either join or leave one or more multicast flows.
The AN will use a Replication Control Response message when conveying
Maglione, et al. Expires January 12, 2009 [Page 30]
Internet-Draft ANCP Multicast Handling July 2008
the outcome of the directive. The message flows in Figure 15
illustrates the behavior of the AN in case of receiving a Replication
Control Request Message.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------>| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| | | Replication-Crl( |
| | | Port ID,add Flow1)|
| | |<--------------------|
| Mcast Flow 1 | |
|<==========================+ |
| | |Replication-Response |
| | | (status) |
| | |-------------------->|
| | | |
| | | |
| | | Replication-Crl( |
| | |Port ID,delete Flow1)|
| | |<--------------------|
| | | |
| <Stop Replication of x |
| Mcast Flow 1> |Replication-Response |
| | | (status) |
| | |-------------------->|
Figure 15: NAS-Controlled Multicast Replication
Maglione, et al. Expires January 12, 2009 [Page 31]
Internet-Draft ANCP Multicast Handling July 2008
6. Security Considerations
Those are addressed in [I-D.ietf-ancp-framework].
Maglione, et al. Expires January 12, 2009 [Page 32]
Internet-Draft ANCP Multicast Handling July 2008
7. IANA Considerations
Not applicable.
Maglione, et al. Expires January 12, 2009 [Page 33]
Internet-Draft ANCP Multicast Handling July 2008
8. Acknowledgements
The authors would like to thank Wojciech Dec for his valuable
comments.
Maglione, et al. Expires January 12, 2009 [Page 34]
Internet-Draft ANCP Multicast Handling July 2008
9. References
9.1. Normative References
[I-D.ietf-ancp-framework]
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",
draft-ietf-ancp-framework-06 (work in progress), May 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002.
9.2. Informative References
[I-D.ietf-ancp-protocol]
Wadhwa, S., "Protocol for Access Node Control Mechanism in
Broadband Networks", draft-ietf-ancp-protocol-02 (work in
progress), November 2007.
Maglione, et al. Expires January 12, 2009 [Page 35]
Internet-Draft ANCP Multicast Handling July 2008
Authors' Addresses
Roberta Maglione
Telecom Italia
Via Reiss Romoli 274
Torino 10148
Italy
Phone:
Email: roberta.maglione@telecomitalia.it
Angelo Garofalo
Telecom Italia
Via Reiss Romoli 274
Torino 10148
Italy
Phone:
Email: angelo.garofalo@telecomitalia.it
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Toerless Eckert
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Phone:
Email: ackert@cisco.com
Maglione, et al. Expires January 12, 2009 [Page 36]
Internet-Draft ANCP Multicast Handling July 2008
Tom Taylor
Huawei Technologies
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
Phone: +1 613 680 2675
Email: tom.taylor@rogers.com
Maglione, et al. Expires January 12, 2009 [Page 37]
Internet-Draft ANCP Multicast Handling July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Maglione, et al. Expires January 12, 2009 [Page 38]