draft-ietf-ancp-mc-extensions-05.txt   draft-ietf-ancp-mc-extensions-06.txt 
ANCP F. Le Faucheur ANCP F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track R. Maglione Intended status: Standards Track R. Maglione
Expires: December 19, 2011 Telecom Italia Expires: June 7, 2012 Telecom Italia
T. Taylor T. Taylor
Huawei Huawei
June 17, 2011 December 5, 2011
Multicast Control Extensions for ANCP Multicast Control Extensions for ANCP
draft-ietf-ancp-mc-extensions-05.txt draft-ietf-ancp-mc-extensions-06.txt
Abstract Abstract
This document specifies the extensions to the Access Node Control This document specifies the extensions to the Access Node Control
Protocol required for support of the multicast use cases defined in Protocol required for support of the multicast use cases defined in
the Access Node Control Protocol framework document and one the Access Node Control Protocol framework document and one
additional use case described in this document. These use cases are additional use case described in this document. These use cases are
organized into the following ANCP capabilities: organized into the following ANCP capabilities:
o NAS-initiated multicast replication; o NAS-initiated multicast replication;
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 19, 2011. This Internet-Draft will expire on June 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 36 skipping to change at page 3, line 36
4.2. Port Management Message . . . . . . . . . . . . . . . . . 17 4.2. Port Management Message . . . . . . . . . . . . . . . . . 17
4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 18 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 18
4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 18 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 18
4.3. Multicast Replication Control Message . . . . . . . . . . 19 4.3. Multicast Replication Control Message . . . . . . . . . . 19
4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 23 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 23
4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 23 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 23
4.4. Multicast Admission Control Message . . . . . . . . . . . 25 4.4. Multicast Admission Control Message . . . . . . . . . . . 25
4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 26 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 26
4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 27 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 27
4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 28 4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 28
4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 29 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 28
4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 29 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 29
4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 31 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 31
4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 32 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 32
4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 32 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 32
4.7. Delegated Bandwidth Query Request Message . . . . . . . . 33 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 33
4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 33
4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34
4.8. Delegated Bandwidth Query Response Message . . . . . . . . 34 4.8. Delegated Bandwidth Query Response Message . . . . . . . . 34
4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34
4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 35 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34
4.9. Multicast Flow Query Request and Response Messages . . . . 35 4.9. Multicast Flow Query Request and Response Messages . . . . 35
4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 36 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 36
4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 37 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 36
4.10. Committed Bandwidth Report Message . . . . . . . . . . . . 38 4.10. Committed Bandwidth Report Message . . . . . . . . . . . . 38
4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 38 4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 38
4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 38 4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 38
5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 40 5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 39
5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 40 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 39
5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 41 5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 40
5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 41 5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 40
5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 44 5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 43
5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 45 5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 44
5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 45 5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 44
5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 46 5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 45
5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 46 5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 45
5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 47 5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 46
5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . . 47 5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . . 46
5.11. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 48 5.11. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 47
5.12. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 49 5.12. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 48
5.13. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 50 5.13. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 49
6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 51 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 50
6.1. Required Protocol Support . . . . . . . . . . . . . . . . 51 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 50
6.1.1. Protocol Requirements For NAS-initiated Replication . 52 6.1.1. Protocol Requirements For NAS-initiated Replication . 51
6.1.2. Protocol Requirements For Committed Multicast 6.1.2. Protocol Requirements For Committed Multicast
Bandwidth Reporting . . . . . . . . . . . . . . . . . 52 Bandwidth Reporting . . . . . . . . . . . . . . . . . 51
6.1.3. Protocol Requirements For Conditional Access With 6.1.3. Protocol Requirements For Conditional Access With
White and Black Lists . . . . . . . . . . . . . . . . 53 White and Black Lists . . . . . . . . . . . . . . . . 52
6.1.4. Protocol Requirements For Conditional Access With 6.1.4. Protocol Requirements For Conditional Access With
Grey Lists . . . . . . . . . . . . . . . . . . . . . . 54 Grey Lists . . . . . . . . . . . . . . . . . . . . . . 53
6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 55 6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 54
6.2. Capability-Specific Procedures for Providing Multicast 6.2. Capability-Specific Procedures for Providing Multicast
Service . . . . . . . . . . . . . . . . . . . . . . . . . 56 Service . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.1. Procedures For NAS-Initiated Replication . . . . . . . 56 6.2.1. Procedures For NAS-Initiated Replication . . . . . . . 55
6.2.2. Procedures For Committed Bandwidth Reporting . . . . 57 6.2.2. Procedures For Committed Bandwidth Reporting . . . . 56
6.2.3. Procedures For Conditional Access With Black and 6.2.3. Procedures For Conditional Access With Black and
White Lists . . . . . . . . . . . . . . . . . . . . . 58 White Lists . . . . . . . . . . . . . . . . . . . . . 57
6.2.4. Procedures For Conditional Access With Grey Lists . . 60 6.2.4. Procedures For Conditional Access With Grey Lists . . 59
6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . . 61 6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . . 60
6.3. Combinations of Multicast Capabilities . . . . . . . . . . 62 6.3. Combinations of Multicast Capabilities . . . . . . . . . . 61
6.3.1. Combination of Conditional Access With White and 6.3.1. Combination of Conditional Access With White and
Black Lists and Conditional Access With Grey Lists . . 62 Black Lists and Conditional Access With Grey Lists . . 61
6.3.2. Combination of Conditional Access With Delegated 6.3.2. Combination of Conditional Access With Delegated
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 63 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 62
6.3.3. Combination of NAS-Initiated Replication with 6.3.3. Combination of NAS-Initiated Replication with
Other Capabilities . . . . . . . . . . . . . . . . . . 63 Other Capabilities . . . . . . . . . . . . . . . . . . 62
6.3.4. Combinations of Committed Bandwidth Reporting with 6.3.4. Combinations of Committed Bandwidth Reporting with
Other Multicast Capabilities . . . . . . . . . . . . . 64 Other Multicast Capabilities . . . . . . . . . . . . . 63
7. Security Considerations . . . . . . . . . . . . . . . . . . . 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 64
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
10.1. Normative References . . . . . . . . . . . . . . . . . . . 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 70
10.2. Informative References . . . . . . . . . . . . . . . . . . 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 70
Appendix A. Example of Messages and Message Flows . . . . . . . . 73 Appendix A. Example of Messages and Message Flows . . . . . . . . 72
A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . . 73 A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . . 72
A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 79 A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 78
A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 84 A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 83
A.4. Handling Of Black-Listed Join Requests . . . . . . . . . . 89 A.4. Handling Of Black-Listed Join Requests . . . . . . . . . . 88
A.5. Handling Of Requests To Join and Leave the On-Line Game . 89 A.5. Handling Of Requests To Join and Leave the On-Line Game . 88
A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 92 A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 91
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95
1. Introduction 1. Introduction
[RFC5851] defines a framework and requirements for an Access Node [RFC5851] defines a framework and requirements for an Access Node
control mechanism between a Network Access Server (NAS) and an Access control mechanism between a Network Access Server (NAS) and an Access
Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a
multi-service reference architecture in order to perform QoS-related, multi-service reference architecture in order to perform QoS-related,
service-related and subscriber-related operations. service-related and subscriber-related operations. [RFC6320]
[I-D.ietf-ancp-protocol] specifies a protocol for Access Node Control specifies a protocol for Access Node Control in broadband networks in
in broadband networks in line with this framework. line with this framework.
[I-D.ietf-ancp-protocol] supports three use cases defined in [RFC6320] supports three use cases defined in [RFC5851], specifically
[RFC5851], specifically for DSL access: the DSL Topology Discovery for DSL access: the DSL Topology Discovery use case, the DSL Line
use case, the DSL Line Configuration use case and the DSL Remote Configuration use case and the DSL Remote Connectivity Test use case.
Connectivity Test use case. However, it does not support the However, it does not support the multicast use cases defined in
multicast use cases defined in [RFC5851]. The present document [RFC5851]. The present document specifies the extensions to the
specifies the extensions to the Access Node Control Protocol required Access Node Control Protocol required for support of these multicast
for support of these multicast use cases. In addition, it supports use cases. In addition, it supports the Committed Bandwidth
the Committed Bandwidth Reporting use case, described below. In Reporting use case, described below. In terms of the ANCP protocol,
terms of the ANCP protocol, these use cases are organized into five these use cases are organized into five capabilities:
capabilities:
o NAS-initiated multicast replication; o NAS-initiated multicast replication;
o conditional access with white and black lists; o conditional access with white and black lists;
o conditional access with grey lists; o conditional access with grey lists;
o bandwidth delegation; o bandwidth delegation;
o committed bandwidth reporting. o committed bandwidth reporting.
skipping to change at page 15, line 13 skipping to change at page 15, line 13
Figure 4: Message Flow For Committed Bandwidth Reporting Figure 4: Message Flow For Committed Bandwidth Reporting
4. ANCP Messages 4. ANCP Messages
This section defines new ANCP messages and new usage of existing ANCP This section defines new ANCP messages and new usage of existing ANCP
messages as well as procedures associated with the use of these messages as well as procedures associated with the use of these
messages. messages.
4.1. Provisioning Message 4.1. Provisioning Message
Section 4.1 of [I-D.ietf-ancp-protocol] defines the Provisioning Section 4.1 of [RFC6320] defines the Provisioning message that is
message that is sent by the NAS to the AN to provision information in sent by the NAS to the AN to provision information in the AN.
the AN.
The present document specifies that the Provisioning message MAY be The present document specifies that the Provisioning message MAY be
used by the NAS to provision multicast-related information (e.g. used by the NAS to provision multicast-related information (e.g.
multicast service profiles). The ANCP Provisioning message payload multicast service profiles). The ANCP Provisioning message payload
MAY contain: MAY contain:
o one or more instances of the Multicast-Service-Profile TLV. The o one or more instances of the Multicast-Service-Profile TLV. The
Multicast- Service-Profile TLV is defined in the present document Multicast- Service-Profile TLV is defined in the present document
in Section 5.1. Each instance of the Multicast-Service-Profile in Section 5.1. Each instance of the Multicast-Service-Profile
TLV contains a multicast service profile name and one or more list TLV contains a multicast service profile name and one or more list
skipping to change at page 17, line 29 skipping to change at page 17, line 27
admission control on the indicated class(es) of flow. If one or both admission control on the indicated class(es) of flow. If one or both
of these TLVs was present in an earlier Provisioning message but is of these TLVs was present in an earlier Provisioning message but is
absent in the latest message received, the AN ceases to do connection absent in the latest message received, the AN ceases to do connection
admission control on the indicated class(es) of flow. admission control on the indicated class(es) of flow.
The buffering time specified in an instance of the Report-Buffering- The buffering time specified in an instance of the Report-Buffering-
Time TLV applies to only to Committed Bandwidth Report messages Time TLV applies to only to Committed Bandwidth Report messages
initiated after the new buffering time is received at the AN, not to initiated after the new buffering time is received at the AN, not to
any message already in the process of accumulation. any message already in the process of accumulation.
As indicated in [I-D.ietf-ancp-protocol], the AN MUST NOT reply to As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning
the Provisioning message if it processed it successfully. If an message if it processed it successfully. If an error prevents
error prevents successful processing of the message content, the AN successful processing of the message content, the AN MUST return a
MUST return a Generic Response message as defined in Generic Response message as defined in [RFC6320], containing a
[I-D.ietf-ancp-protocol], containing a Status-Info TLV with the Status-Info TLV with the appropriate content describing the error.
appropriate content describing the error. For this purpose, the For this purpose, the presence of a list type in a Multicast-Service-
presence of a list type in a Multicast-Service-Profile TLV which was Profile TLV which was ignored because it was not supported by the
ignored because it was not supported by the negotiated set of negotiated set of capabilities is not considered to be an error.
capabilities is not considered to be an error.
4.2. Port Management Message 4.2. Port Management Message
As specified in [I-D.ietf-ancp-protocol], the NAS may send DSL line As specified in [RFC6320], the NAS may send DSL line configuration
configuration information to the AN ("ANCP based DSL Line information to the AN ("ANCP based DSL Line Configuration" use case)
Configuration" use case) using ANCP Port Management messages. See using ANCP Port Management messages. See Section 7.3 of [RFC6320]
Section 7.3 of [I-D.ietf-ancp-protocol] for the format of the Port for the format of the Port Management message in that usage.
Management message in that usage.
This document specifies that the Port Management message MAY be used This document specifies that the Port Management message MAY be used
to convey either or both of the following TLVs: to convey either or both of the following TLVs:
o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This
TLV associates a Multicast Service Profile with the Access Port TLV associates a Multicast Service Profile with the Access Port
specified by the extension block. specified by the extension block.
o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV
specifies the total multicast bandwidth available to the AN for specifies the total multicast bandwidth available to the AN for
admission control at the Access Port. admission control at the Access Port.
When used for this purpose, the Port Management message MUST include When used for this purpose, the Port Management message MUST include
TLV(s) to identify the access line concerned. If the access line is TLV(s) to identify the access line concerned. If the access line is
a DSL loop, the line-identifying TLV(s) MUST be as specified in a DSL loop, the line-identifying TLV(s) MUST be as specified in
Section 5.1.2 of [I-D.ietf-ancp-protocol]. For non-DSL access lines, Section 5.1.2 of [RFC6320]. For non-DSL access lines, the
the appropriate alternative line-identifying TLV(s) MUST be present. appropriate alternative line-identifying TLV(s) MUST be present.
Line configuration data other than the two TLVs listed in the Line configuration data other than the two TLVs listed in the
previous paragraph MAY be present. previous paragraph MAY be present.
4.2.1. Sender Behaviour 4.2.1. Sender Behaviour
The NAS sends the Port Management message at startup time to The NAS sends the Port Management message at startup time to
initialize parameters associated with the Access Port specified in initialize parameters associated with the Access Port specified in
the message and with the multicast capabilities negotiated between the message and with the multicast capabilities negotiated between
the NAS and the AN. The NAS MAY send additional Port Management the NAS and the AN. The NAS MAY send additional Port Management
messages subsequent to startup, to update or, in the case of the messages subsequent to startup, to update or, in the case of the
skipping to change at page 19, line 30 skipping to change at page 19, line 28
by the NAS to the AN with one or more directives to add (join) or by the NAS to the AN with one or more directives to add (join) or
delete (leave) a multicast flow on a target object identified in the delete (leave) a multicast flow on a target object identified in the
content of the message. content of the message.
The Message Type for the Multicast Replication Control message is The Message Type for the Multicast Replication Control message is
144. 144.
The ANCP Multicast Replication Control message payload contains the The ANCP Multicast Replication Control message payload contains the
following TLVs: following TLVs:
o Target TLV: The Target TLV is defined in Section 4.3 of o Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320].
[I-D.ietf-ancp-protocol]. It MUST appear once and only once. It It MUST appear once and only once. It is encoded as specified in
is encoded as specified in [I-D.ietf-ancp-protocol] or extensions [RFC6320] or extensions and identifies the AN port subject to the
and identifies the AN port subject to the request for admission or request for admission or release.
release.
o Command TLV: The Command TLV is defined in Section 4.4 of o Command TLV: The Command TLV is defined in Section 4.4 of
[I-D.ietf-ancp-protocol]. It MUST be present. It MAY appear [RFC6320]. It MUST be present. It MAY appear multiple times.
multiple times.
As [I-D.ietf-ancp-protocol] indicates, the contents of the Command As [RFC6320] indicates, the contents of the Command Info field within
Info field within the Command TLV are specific to the message in the Command TLV are specific to the message in which the TLV occurs.
which the TLV occurs. For the Multicast Replication Control Message, For the Multicast Replication Control Message, these contents consist
these contents consist of: of:
o a Command Code field; o a Command Code field;
o an Accounting field; o an Accounting field;
o an instance of the Multicast-Flow TLV. o an instance of the Multicast-Flow TLV.
Figure 5 illustrates the complete Command TLV with the contents Figure 5 illustrates the complete Command TLV with the contents
specific to the Multicast Replication Control message. specific to the Multicast Replication Control message.
skipping to change at page 23, line 24 skipping to change at page 23, line 24
field to AckAll (0x2) or Nack (0x1) according to its requirements. field to AckAll (0x2) or Nack (0x1) according to its requirements.
The NAS MAY also send this message in response to a Multicast The NAS MAY also send this message in response to a Multicast
Admission Control message (defined in Section 4.4) received from the Admission Control message (defined in Section 4.4) received from the
AN to support the conditional access and admission control use case AN to support the conditional access and admission control use case
presented in [RFC5851] and summarized in Section 3.2. In that case, presented in [RFC5851] and summarized in Section 3.2. In that case,
the NAS MUST set the Result field to NAck (0x1). the NAS MUST set the Result field to NAck (0x1).
In either case, the sender MUST populate the Result Code field with In either case, the sender MUST populate the Result Code field with
the value 0x000 and the ANCP Transaction Identifier field with a the value 0x000 and the ANCP Transaction Identifier field with a
unique value, as described in Section 3.6.1.6 of unique value, as described in Section 3.6.1.6 of [RFC6320].
[I-D.ietf-ancp-protocol].
Each Multicast Replication Control Message MUST contain one or more Each Multicast Replication Control Message MUST contain one or more
commands, each encapsulated in its own Command TLV. The sender MUST commands, each encapsulated in its own Command TLV. The sender MUST
use a separate Command TLV for each distinct multicast flow. use a separate Command TLV for each distinct multicast flow.
When the order of processing of two commands does not matter, the When the order of processing of two commands does not matter, the
commands MUST be transmitted in separate Multicast Replication commands MUST be transmitted in separate Multicast Replication
Control messages. Control messages.
4.3.2. Receiver Behaviour 4.3.2. Receiver Behaviour
skipping to change at page 24, line 37 skipping to change at page 24, line 36
The processing/execution of multiple commands contained in a single The processing/execution of multiple commands contained in a single
Multicast Control message MUST be interrupted at the first error Multicast Control message MUST be interrupted at the first error
encountered, and the remaining commands in the Multicast Replication encountered, and the remaining commands in the Multicast Replication
Control message discarded. Control message discarded.
If the AN detects an error in a received Multicast Replication If the AN detects an error in a received Multicast Replication
Control message and the Result field in that message was set to Nack Control message and the Result field in that message was set to Nack
(0x1) or AckAll(0x2), the AN MUST generate a Generic Response message (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message
providing error information to the NAS. This specification providing error information to the NAS. This specification
identifies the following new Result Code values beyond those identifies the following new Result Code values beyond those
specified in [I-D.ietf-ancp-protocol], which MAY be used in a Generic specified in [RFC6320], which MAY be used in a Generic Response sent
Response sent in reply to a Multicast Replication Control message: in reply to a Multicast Replication Control message:
100 Command error. This SHOULD be reported for the case that an 100 Command error. This SHOULD be reported for the case that an
invalid command code has been received. invalid command code has been received.
101 Bad flow address. This SHOULD be reported for the following 101 Bad flow address. This SHOULD be reported for the following
cases: cases:
* unsupported address family; * unsupported address family;
* source address present for an ASM flow, or absent for an SSM * source address present for an ASM flow, or absent for an SSM
skipping to change at page 25, line 36 skipping to change at page 25, line 36
This section defines a new message called the Multicast Admission This section defines a new message called the Multicast Admission
Control message. The Multicast Admission Control message is sent by Control message. The Multicast Admission Control message is sent by
the AN to the NAS to request admission of a multicast flow, or to the AN to the NAS to request admission of a multicast flow, or to
notify of the removal of a multicast flow, for a given target. notify of the removal of a multicast flow, for a given target.
The Message Type for the Multicast Admission Control message is 145. The Message Type for the Multicast Admission Control message is 145.
The ANCP Multicast Admission Control message payload contains two The ANCP Multicast Admission Control message payload contains two
TLVs: TLVs:
o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. o Target TLV: The Target TLV is defined in [RFC6320]. It MUST
It MUST appear once and only once in the Multicast Admission appear once and only once in the Multicast Admission Control
Control message. It is encoded as specified in message. It is encoded as specified in [RFC6320] or extensions
[I-D.ietf-ancp-protocol] or extensions and identifies the AN port and identifies the AN port subject to the request for admission or
subject to the request for admission or release. release.
o Command TLV: The Command TLV is defined in o Command TLV: The Command TLV is defined in [RFC6320]. It MUST be
[I-D.ietf-ancp-protocol]. It MUST be present. If it appears more present. If it appears more than once, only the first instance is
than once, only the first instance is considered meaningful in the considered meaningful in the present version of this specification
present version of this specification and the other instances are and the other instances are ignored.
ignored.
Informative note: Informative note:
In the future, the specification of the Admission Control message In the future, the specification of the Admission Control message
may be extended to allow transport of more than a single directive may be extended to allow transport of more than a single directive
(e.g. to carry both a leave from one group and a join to another (e.g. to carry both a leave from one group and a join to another
group for the same Target). It is expected that this would group for the same Target). It is expected that this would
support a similar notion of strict sequenced processing as support a similar notion of strict sequenced processing as
currently defined for handling multiple directives in the currently defined for handling multiple directives in the
Multicast Replication Control message whereby all directives Multicast Replication Control message whereby all directives
skipping to change at page 26, line 31 skipping to change at page 26, line 30
Note that the Command TLV length includes the length of any embedded Note that the Command TLV length includes the length of any embedded
TLVs, including the embedded TLV headers. TLVs, including the embedded TLV headers.
4.4.1. Sender Behaviour 4.4.1. Sender Behaviour
The AN sending the Multicast Admission Control message MUST set the The AN sending the Multicast Admission Control message MUST set the
Result field to Ignore (0x0). Result field to Ignore (0x0).
The AN MUST populate the ANCP Transaction Identifier field with a The AN MUST populate the ANCP Transaction Identifier field with a
unique value, as described in Section 3.6.1.6 of unique value, as described in Section 3.6.1.6 of [RFC6320] .
[I-D.ietf-ancp-protocol] .
The AN MUST encode the Command TLV as specified in Section 4.3 with The AN MUST encode the Command TLV as specified in Section 4.3 with
the following additional rules: the following additional rules:
o the Accounting field MUST be set to 0; o the Accounting field MUST be set to 0;
o the Command Code field MUST be set to "0x01 - Add" when the o the Command Code field MUST be set to "0x01 - Add" when the
message conveys a Join , to "0x02 - Delete" when the message message conveys a Join , to "0x02 - Delete" when the message
conveys a Leave and to "0x03 - Delete All" when the message conveys a Leave and to "0x03 - Delete All" when the message
conveys a Leave of all channels (on the target); conveys a Leave of all channels (on the target);
skipping to change at page 28, line 22 skipping to change at page 28, line 20
adjacency); adjacency);
* MUST contain the directive rejected by the NAS (i.e. Target * MUST contain the directive rejected by the NAS (i.e. Target
TLV and Command TLV) but with a Command Code set to "0x04 - TLV and Command TLV) but with a Command Code set to "0x04 -
Admission Control Reject", "0x05 - Conditional Access Reject", Admission Control Reject", "0x05 - Conditional Access Reject",
or "0x06 - Admission Control and Conditional Access Reject". or "0x06 - Admission Control and Conditional Access Reject".
o if the Multicast Admission Control message cannot be processed o if the Multicast Admission Control message cannot be processed
correctly by the NAS (e.g. the message is malformed, the multicast correctly by the NAS (e.g. the message is malformed, the multicast
flow does not exist etc.), the NAS MUST generate a Generic flow does not exist etc.), the NAS MUST generate a Generic
Response message (defined in Section 4.2 of Response message (defined in Section 4.2 of [RFC6320]) with
[I-D.ietf-ancp-protocol]) with appropriate content indicating the appropriate content indicating the reason for the failure.
reason for the failure.
4.5. Bandwidth Reallocation Request Message 4.5. Bandwidth Reallocation Request Message
The Bandwidth Reallocation Request message is used when the bandwidth The Bandwidth Reallocation Request message is used when the bandwidth
delegation capability is included in the negotiated set. It MAY be delegation capability is included in the negotiated set. It MAY be
sent either by the NAS or by the AN to request an adjustment in the sent either by the NAS or by the AN to request an adjustment in the
amount of delegated bandwidth. It will be sent by the NAS typically amount of delegated bandwidth. It will be sent by the NAS typically
to reduce the multicast bandwidth allocated to the AN in order for to reduce the multicast bandwidth allocated to the AN in order for
the NAS to satisfy a request to add one or more flows. Conversely, the NAS to satisfy a request to add one or more flows. Conversely,
the AN will send a Bandwidth Reallocation Request to obtain the AN will send a Bandwidth Reallocation Request to obtain
additional bandwidth to satisfy a request to add a multicast channel. additional bandwidth to satisfy a request to add a multicast channel.
In each case, the requestor has a minimum requirement for additional In each case, the requestor has a minimum requirement for additional
bandwidth, and MAY ask for additional bandwidth beyond this amount bandwidth, and MAY ask for additional bandwidth beyond this amount
(e.g., to handle anticipated future requests). (e.g., to handle anticipated future requests).
The Bandwidth Reallocation Request message contains two TLVs: The Bandwidth Reallocation Request message contains two TLVs:
o the Target TLV (Section 4.3 of [I-D.ietf-ancp-protocol] or an o the Target TLV (Section 4.3 of [RFC6320] or an extension),
extension), specifying a single access line; specifying a single access line;
o the Bandwidth-Request TLV (Section 5.8), specifying the required o the Bandwidth-Request TLV (Section 5.8), specifying the required
and preferred amounts of delegated bandwidth. and preferred amounts of delegated bandwidth.
The Message Type for the Bandwidth Reallocation Request message is The Message Type for the Bandwidth Reallocation Request message is
146. 146.
4.5.1. Sender Behaviour 4.5.1. Sender Behaviour
The Result field in the header of the Bandwidth Reallocation Request The Result field in the header of the Bandwidth Reallocation Request
skipping to change at page 34, line 11 skipping to change at page 34, line 5
o a Target TLV designating the access line for which the information o a Target TLV designating the access line for which the information
is requested. is requested.
4.7.1. Sender Behaviour 4.7.1. Sender Behaviour
The sender MUST set the Result field in the header of the Delegated The sender MUST set the Result field in the header of the Delegated
Bandwidth Query Request message to AckAll (0x2). The Result Code Bandwidth Query Request message to AckAll (0x2). The Result Code
value MUST be set to 0x000. The sender MUST populate the ANCP value MUST be set to 0x000. The sender MUST populate the ANCP
Transaction Identifier field with a unique value, as described in Transaction Identifier field with a unique value, as described in
Section 3.6.1.6 of [I-D.ietf-ancp-protocol]. Section 3.6.1.6 of [RFC6320].
4.7.2. Receiver Behaviour 4.7.2. Receiver Behaviour
If the AN or NAS receives a valid Delegated Bandwidth Query Request If the AN or NAS receives a valid Delegated Bandwidth Query Request
message, it MUST respond with a Delegated Bandwidth Query Response message, it MUST respond with a Delegated Bandwidth Query Response
message. The Result field in the header of the response MUST be set message. The Result field in the header of the response MUST be set
to Success (0x3). The Result Code field MUST be set to 0x000. The to Success (0x3). The Result Code field MUST be set to 0x000. The
Transaction-Id field MUST be copied from the request message. The Transaction-Id field MUST be copied from the request message. The
body of the response MUST contain the Target TLV, copied from the body of the response MUST contain the Target TLV, copied from the
request message. Finally, the body of the response MUST contain a request message. Finally, the body of the response MUST contain a
skipping to change at page 36, line 18 skipping to change at page 36, line 14
The contents of the Multicast Flow Query Request and Response depend The contents of the Multicast Flow Query Request and Response depend
on the nature of the query, as described below. on the nature of the query, as described below.
4.9.1. Sender Behaviour 4.9.1. Sender Behaviour
The sender of a Multicast Flow Query Request message MUST set the The sender of a Multicast Flow Query Request message MUST set the
Result field to AckAll (0x2). The Result Code field MUST be set to Result field to AckAll (0x2). The Result Code field MUST be set to
0x000. The sender MUST populate the ANCP Transaction Identifier 0x000. The sender MUST populate the ANCP Transaction Identifier
field with a unique value, as described in section 3.6.1.6 of field with a unique value, as described in section 3.6.1.6 of
[I-D.ietf-ancp-protocol]. [RFC6320].
The Multicast Flow Query Request MAY be used by the NAS to retrieve: The Multicast Flow Query Request MAY be used by the NAS to retrieve:
o the AN's view of which multicast flows are currently active on a o the AN's view of which multicast flows are currently active on a
specified set of access ports; or specified set of access ports; or
o the AN's view of the access ports on which a specified set of o the AN's view of the access ports on which a specified set of
multicast flows are currently active; or multicast flows are currently active; or
o the AN's view of all the multicast flows currently active on each o the AN's view of all the multicast flows currently active on each
and every port of the AN. and every port of the AN.
To retrieve the AN's view of which multicast flows are currently To retrieve the AN's view of which multicast flows are currently
active on a given port of the AN, the NAS MUST include a Target TLV active on a given port of the AN, the NAS MUST include a Target TLV
in the Multicast Flow Query Request payload identifying that port. in the Multicast Flow Query Request payload identifying that port.
The Target TLV is encoded as specified in [I-D.ietf-ancp-protocol]. The Target TLV is encoded as specified in [RFC6320].
To retrieve the AN's view of the ports currently receiving a given To retrieve the AN's view of the ports currently receiving a given
multicast flow, the NAS MUST include a Multicast-Flow TLV in the multicast flow, the NAS MUST include a Multicast-Flow TLV in the
Multicast Flow Query Request payload identifying that flow. The Multicast Flow Query Request payload identifying that flow. The
Multicast-Flow TLV is encoded as specified in Section 5.11. Multicast-Flow TLV is encoded as specified in Section 5.11.
The NAS MAY include multiple Target TLVs or multiple Multicast-Flow The NAS MAY include multiple Target TLVs or multiple Multicast-Flow
TLVs in the Multicast Flow Query Request, but MUST NOT include both TLVs in the Multicast Flow Query Request, but MUST NOT include both
Target and Multicast-Flow TLVs in the same message. Target and Multicast-Flow TLVs in the same message.
skipping to change at page 38, line 31 skipping to change at page 38, line 23
The Committed Bandwidth Report message contains one or more instances The Committed Bandwidth Report message contains one or more instances
of the Committed-Bandwidth TLV, as described in Section 5.13. of the Committed-Bandwidth TLV, as described in Section 5.13.
4.10.1. Sender Behaviour 4.10.1. Sender Behaviour
The sender of a Committed Bandwidth Report message MUST set the The sender of a Committed Bandwidth Report message MUST set the
Result field to Ignore (0x0). The Result Code field MUST be set to Result field to Ignore (0x0). The Result Code field MUST be set to
0x000. The sender MUST populate the ANCP Transaction Identifier 0x000. The sender MUST populate the ANCP Transaction Identifier
field with a unique value, as described in section 3.6.1.6 of field with a unique value, as described in section 3.6.1.6 of
[I-D.ietf-ancp-protocol]. [RFC6320].
Each instance of the Committed-Bandwidth TLV included in the message Each instance of the Committed-Bandwidth TLV included in the message
MUST identify an access line for which the amount of committed MUST identify an access line for which the amount of committed
multicast bandwidth has changed since the previous Committed multicast bandwidth has changed since the previous Committed
Bandwidth Report message was sent and MUST report the latest amount Bandwidth Report message was sent and MUST report the latest amount
of multicast bandwidth committed to that line. There MUST be only of multicast bandwidth committed to that line. There MUST be only
one instance of the Committed-Bandwidth TLV present in the message one instance of the Committed-Bandwidth TLV present in the message
for any given access line. The message MUST include an instance of for any given access line. The message MUST include an instance of
the Committed-Bandwidth TLV for every access line for which committed the Committed-Bandwidth TLV for every access line for which committed
multicast bandwidth has changed since the previous Committed multicast bandwidth has changed since the previous Committed
skipping to change at page 51, line 7 skipping to change at page 50, line 7
its header and any padding. its header and any padding.
o Committed Multicast Bandwidth is a 32-bit unsigned integer o Committed Multicast Bandwidth is a 32-bit unsigned integer
providing a bandwidth amount in kbits/s. providing a bandwidth amount in kbits/s.
o The Target TLV identifies the access line to which this amount of o The Target TLV identifies the access line to which this amount of
multicast bandwidth is currently committed. multicast bandwidth is currently committed.
6. Multicast Capabilities 6. Multicast Capabilities
Section 3.5 of [I-D.ietf-ancp-protocol] defines a capability Section 3.5 of [RFC6320] defines a capability negotiation mechanism
negotiation mechanism as well as a number of capabilities. This as well as a number of capabilities. This section defines five new
section defines five new capabilities in support of different modes capabilities in support of different modes of multicast operation:
of multicast operation:
o NAS-initiated replication (capability type 0x03); o NAS-initiated replication (capability type 0x03);
o committed multicast bandwidth reporting (capability type 0x05); o committed multicast bandwidth reporting (capability type 0x05);
o conditional access with white and black lists (capability type o conditional access with white and black lists (capability type
0x06); 0x06);
o conditional access with grey lists (capability type 0x07); o conditional access with grey lists (capability type 0x07);
skipping to change at page 51, line 41 skipping to change at page 50, line 40
specifies how the capabilities interact if more than one multicast specifies how the capabilities interact if more than one multicast
capability is included in the set of capabilities negotiated between capability is included in the set of capabilities negotiated between
the AN and the NAS. the AN and the NAS.
Note that if a request contains content that is not supported Note that if a request contains content that is not supported
(according to the tables in Section 6.1) by the negotiated set of (according to the tables in Section 6.1) by the negotiated set of
multicast capabilities, the appropriate response is to return a multicast capabilities, the appropriate response is to return a
Generic Response message indicating Failure (0x4) with an appropriate Generic Response message indicating Failure (0x4) with an appropriate
code value (e.g., 84 "TLV or value not supported by negotiated code value (e.g., 84 "TLV or value not supported by negotiated
capability set"). The body of the message MUST contain a Status-Info capability set"). The body of the message MUST contain a Status-Info
TLV. See Sections 4.2 and 4.5 in [I-D.ietf-ancp-protocol] for more TLV. See Sections 4.2 and 4.5 in [RFC6320] for more details.
details.
6.1. Required Protocol Support 6.1. Required Protocol Support
This section specifies the protocol elements that MUST be implemented This section specifies the protocol elements that MUST be implemented
to support each of the four multicast capabilities. Support of to support each of the four multicast capabilities. Support of
multiple multicast capabilities requires implementation of the union multiple multicast capabilities requires implementation of the union
of the sets of protocol elements applying to each of the individual of the sets of protocol elements applying to each of the individual
capabilities in the supported set. capabilities in the supported set.
6.1.1. Protocol Requirements For NAS-initiated Replication 6.1.1. Protocol Requirements For NAS-initiated Replication
skipping to change at page 65, line 7 skipping to change at page 64, line 7
Committed bandwidth reporting can take independently of which other Committed bandwidth reporting can take independently of which other
multicast capabilities have been negotiated. However, some multicast capabilities have been negotiated. However, some
combinations do not make sense because of redundancy. In particular, combinations do not make sense because of redundancy. In particular,
the NAS obtains the same information that committed bandwidth the NAS obtains the same information that committed bandwidth
reporting gives if the only other capabilities operating are NAS- reporting gives if the only other capabilities operating are NAS-
initiated replication and/or conditional access with Grey lists. initiated replication and/or conditional access with Grey lists.
7. Security Considerations 7. Security Considerations
The security considerations of ANCP are discussed in The security considerations of ANCP are discussed in [RFC6320] and in
[I-D.ietf-ancp-protocol] and in [RFC5713]. [RFC5713].
8. IANA Considerations 8. IANA Considerations
IANA NOTE: Please replace XXXX with the RFC number of this document. IANA NOTE: Please replace XXXX with the RFC number of this document.
This document defines the following additional values within the ANCP This document defines the following additional values within the ANCP
Message Type Name Space registry: Message Type Name Space registry:
+--------------+--------------------------------+-----------+ +--------------+--------------------------------+-----------+
| Message Type | Message Name | Reference | | Message Type | Message Name | Reference |
skipping to change at page 71, line 9 skipping to change at page 70, line 9
that formed the base of the Multicast Flow Reporting solution. that formed the base of the Multicast Flow Reporting solution.
Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided
substantial contributions on the solution for the NAS initiated substantial contributions on the solution for the NAS initiated
multicast control use case. Kristian Poscic provided the committed multicast control use case. Kristian Poscic provided the committed
bandwidth reporting use case. bandwidth reporting use case.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ancp-protocol]
Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
Taylor, "Protocol for Access Node Control Mechanism in
Broadband Networks", draft-ietf-ancp-protocol-17 (work in
progress), April 2011.
[IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ [IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
EUI48.html", 2010. EUI48.html", 2010.
[IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ [IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html", 2010. EUI64.html", 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
skipping to change at page 71, line 39 skipping to change at page 70, line 33
"General Switch Management Protocol (GSMP) V3", RFC 3292, "General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002. June 2002.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
Taylor, "Protocol for Access Node Control Mechanism in
Broadband Networks", RFC 6320, October 2011.
10.2. Informative References 10.2. Informative References
[I-D.morin-mboned-igmpmld-error-feedback] [I-D.morin-mboned-igmpmld-error-feedback]
Morin, T. and B. Haberman, "IGMP/MLD Error Feedback", Morin, T. and B. Haberman, "IGMP/MLD Error Feedback",
draft-morin-mboned-igmpmld-error-feedback-02 (work in draft-morin-mboned-igmpmld-error-feedback-02 (work in
progress), November 2008. progress), November 2008.
[PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/pim- [PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/pim-
parameters.xhtml", 2005. parameters.xhtml", 2005.
 End of changes. 43 change blocks. 
136 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/