< draft-liu-pim-assert-packing-00.txt   draft-liu-pim-assert-packing-01.txt >
PIM Working Group Yisong Liu PIM Working Group Yisong Liu
Internet Draft M. McBride Internet Draft Huawei Technologies
Intended status: Standards Track T. Eckert Intended status: Standards Track M. McBride
Expires: September 6, 2019 Huawei Technologies Expires: December 20, 2019 T. Eckert
March 6, 2019 Futurewei
June 20, 2019
PIM Assert Message Packing PIM Assert Message Packing
draft-liu-pim-assert-packing-00 draft-liu-pim-assert-packing-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 33
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 6, 2019. This Internet-Draft will expire on December 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
In PIM-SM shared networks, there is typically more than one upstream
router. When duplicate data packets appear on the LAN from different In PIM-SM shared LAN networks, there is typically more than one
routers, assert packets are sent from these routers to elect a single upstream router. When duplicate data packets appear on the LAN from
forwarder. The PIM assert packets are sent periodically to keep the different routers, assert packets are sent from these routers to
assert state. The PIM assert packet carries information about a elect a single forwarder. The PIM assert packets are sent
single multicast source and group, along with the metric-preference periodically to keep the assert state. The PIM assert packet carries
and metric of the route towards the source or RP. This document information about a single multicast source and group, along with the
defines a standard to send and receive multiple multicast source and metric-preference and metric of the route towards the source or RP.
group information in a single PIM assert packet in a shared network. This document defines a standard to send and receive multiple
This can be particularly helpful when there is traffic for a large multicast source and group information in a single PIM assert packet
number of multicast groups. in a shared network. This can be particularly helpful when there is
traffic for a large number of multicast groups.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
1.1. Requirements Language .................................. 3 1.1. Requirements Language .................................. 3
1.2. Terminology ............................................ 3 1.2. Terminology ............................................ 3
2. Use Cases ................................................... 3 2. Use Cases ................................................... 3
2.1. Enterprise network ..................................... 3 2.1. Enterprise network ..................................... 3
2.2. Video surveillance ..................................... 3 2.2. Video surveillance ..................................... 4
2.3. Financial Services ..................................... 4 2.3. Financial Services ..................................... 4
2.4. IPTV broadcast video ................................... 4 2.4. IPTV broadcast video ................................... 4
3. Solution .................................................... 4 2.5. Summary ................................................ 4
3. Solution .................................................... 5
3.1. PIM Assert Packing Hello Option ........................ 5 3.1. PIM Assert Packing Hello Option ........................ 5
3.2. PIM Assert Packing Simple Type ......................... 5 3.2. PIM Assert Packing Simple Type ......................... 5
3.3. PIM Assert Packing Aggregation Type .................... 5 3.3. PIM Assert Packing Aggregation Type .................... 5
4. Packet Format ............................................... 5 4. Packet Format ............................................... 6
4.1. PIM Assert Packing Hello Option ........................ 6 4.1. PIM Assert Packing Hello Option ........................ 6
4.2. PIM Assert Simple Packing Format ....................... 6 4.2. PIM Assert Simple Packing Format ....................... 7
4.3. PIM Assert Aggregation Packing Format .................. 7 4.3. PIM Assert Aggregation Packing Format .................. 8
5. IANA Considerations ......................................... 9 5. IANA Considerations ........................................ 11
6. Security Considerations ..................................... 9 6. Security Considerations .................................... 11
7. References .................................................. 9 7. References ................................................. 11
7.1. Normative References ................................... 9 7.1. Normative References .................................. 11
7.2. Informative References ................................ 10 7.2. Informative References ................................ 11
8. Acknowledgments ............................................ 10 8. Acknowledgments ............................................ 12
1. Introduction 1. Introduction
In PIM-SM shared networks, there is typically more than one upstream In PIM-SM shared LAN networks, there is typically more than one
router. When duplicate data packets appear on the LAN, from upstream router. When duplicate data packets appear on the LAN, from
different upstream routers, assert packets are sent from these different upstream routers, assert packets are sent from these
routers to elect a single forwarder according to [RFC7761]. The PIM routers to elect a single forwarder according to [RFC7761]. The PIM
assert packets are sent periodically to keep the assert state. The assert packets are sent periodically to keep the assert state. The
PIM assert packet carries information about a single multicast PIM assert packet carries information about a single multicast
source and group, along with the corresponding metric-preference and source and group, along with the corresponding metric-preference and
metric of the route towards the source or RP. metric of the route towards the source or RP.
This document defines a standard to send and receive multiple This document defines a standard to send and receive multiple
multicast source and group information in a single PIM assert packet multicast source and group information in a single PIM assert packet
in a shared network. It can efficiently pack multiple PIM assert in a shared LAN network. It can efficiently pack multiple PIM assert
packets into a single message and reduce the processing pressure of packets into a single message and reduce the processing pressure of
the PIM routers. This can be particularly helpful when there is the PIM routers. This can be particularly helpful when there is
traffic for a large number of multicast groups. traffic for a large number of multicast groups.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 3, line 32 skipping to change at page 3, line 34
1.2. Terminology 1.2. Terminology
RPF: Reverse Path Forwarding RPF: Reverse Path Forwarding
RP: Rendezvous Point RP: Rendezvous Point
SPT: Shortest Path Tree SPT: Shortest Path Tree
RPT: RP Tree RPT: RP Tree
DR: Designated Router
BDR: Backup Designated Router
2. Use Cases 2. Use Cases
PIM Asserts will happen in many services where multicast is used and PIM Assert will happen in many services where multicast is used and
not limited to the examples described below: not limited to the examples described below.
2.1. Enterprise network 2.1. Enterprise network
When an Enterprise network is connected through a layer-2 network, When an Enterprise network is connected through a layer-2 network,
the intra-enterprise runs layer-3 PIM multicast. The different sites the intra-enterprise runs layer-3 PIM multicast. The different sites
of the enterprise are equivalent to the PIM connection through the of the enterprise are equivalent to the PIM connection through the
shared network. Depending upon the locations and amount of groups shared LAN network. Depending upon the locations and amount of
there could be many asserts on the first hop routers. groups there could be many asserts on the first hop routers.
2.2. Video surveillance 2.2. Video surveillance
Video surveillance deployments have migrated from analog based Video surveillance deployments have migrated from analog based
systems to IP-based systems oftentimes using multicast. In certain systems to IP-based systems oftentimes using multicast. In the
deployments, when there are many cameras streaming to many groups, shared LAN network deployments, when there are many cameras
there may be issues with many asserts on first hop routers. streaming to many groups there may be issues with many asserts on
first hop routers.
2.3. Financial Services 2.3. Financial Services
Financial services extensively rely on IP Multicast to deliver stock Financial services extensively rely on IP Multicast to deliver stock
market data and its derivatives, and current multicast solution PIM market data and its derivatives, and current multicast solution PIM
is usually deployed. As the number of multicast flows grows, there is usually deployed. As the number of multicast flows grows, there
are many stock data with many groups may result in many PIM asserts are many stock data with many groups may result in many PIM asserts
on a shared network from publisher to the subscribers. on a shared LAN network from publisher to the subscribers.
2.4. IPTV broadcast video 2.4. IPTV broadcast video
PIM DR and BDR deployments are often used in host-side network for PIM DR and BDR deployments are often used in host-side network for
IPTV broadcast video services. Host-side access network failure IPTV broadcast video services. Host-side access network failure
scenario may be benefitted by assert packing when many groups are scenario may be benefitted by assert packing when many groups are
being used. According to [RFC7761] the DR will be elected to forward being used. According to [RFC7761] the DR will be elected to forward
multicast traffic in the shared access network. When the DR recovers multicast traffic in the shared access network. When the DR recovers
from a failure, the original DR starts to send traffic, and the from a failure, the original DR starts to send traffic, and the
current DR is still forwarding traffic. In the situation multicast current DR is still forwarding traffic. In the situation multicast
traffic duplication maybe happen in the shared access network and traffic duplication maybe happen in the shared access network and
can trigger the assert progress. can trigger the assert progress.
In the above scenarios, as the multicast service becomes widely 2.5. Summary
deployed, the number of multicast entries increases, and a large
number of assert messages may be sent in a very short period when In the above scenarios, the existence of PIM assert process depends
multicast data packets trigger PIM assert process in the shared mainly on the network topology. As long as there is a layer 2
networks. The PIM routers need to process a large number of PIM network between PIM neighbors, there may be multiple upstream
assert small packets in a very short time. As a result, the device routers, which can cause duplicate multicast traffic to be forwarded
load is very large. The assert packet may not be processed in time and assert process to occur.
or even is discarded, thus extending the time of traffic duplication
in the network. Moreover as the multicast services become widely deployed, the
number of multicast entries increases, and a large number of assert
messages may be sent in a very short period when multicast data
packets trigger PIM assert process in the shared LAN networks. The
PIM routers need to process a large number of PIM assert small
packets in a very short time. As a result, the device load is very
large. The assert packet may not be processed in time or even is
discarded, thus extending the time of traffic duplication in the
network.
Additionally, future backhaul, or fronthaul, networks may want to Additionally, future backhaul, or fronthaul, networks may want to
connect L3 across an L2 underlay supporting Time Sensitive Networks connect L3 across an L2 underlay supporting Time Sensitive Networks
(TSN). The infrastructure may run DetNet over TSN. These transit L2 (TSN). The infrastructure may run DetNet over TSN. These transit L2
LANs would have multiple upstreams and downstreams. This draft is LANs would have multiple upstreams and downstreams. This document is
taking a proactive approach to prevention of possible future assert taking a proactive approach to prevention of possible future assert
issues in these types of environments. issues in these types of environments.
3. Solution 3. Solution
The change to the PIM assert includes two elements: the PIM assert The change to the PIM assert includes two elements: the PIM assert
packing hello option and the PIM assert packing method. packing hello option and the PIM assert packing method.
There is no change required to the PIM assert state machine. There is no change required to the PIM assert state machine.
Basically a PIM router can now be the assert winner/loser for Basically a PIM router can now be the assert winner or loser for
multiple packed (S, G)'s in a single assert packet instead of one multiple packed (S, G)'s in a single assert packet instead of one
(S, G) assert at a time. An assert winner is now responsible for (S, G) assert at a time. An assert winner is now responsible for
forwarding traffic from multiple (S, G)'s out of a particular forwarding traffic from multiple (S, G)'s out of a particular
interface based upon the multiple (S, G)'s packed in a single interface based upon the multiple (S, G)'s packed in a single
assert. assert.
3.1. PIM Assert Packing Hello Option 3.1. PIM Assert Packing Hello Option
The newly defined Hello Option is used by a router to negotiate the The newly defined Hello Option is used by a router to negotiate the
assert packet packing capability. It can only be used when all PIM assert packet packing capability. It can only be used when all PIM
routers, in the same shared network, support this capability. routers, in the same shared LAN network, support this capability.
This document defines two packing methods. One method is a simple This document defines two packing methods. One method is a simple
merge of the original messages and the other is to extract the merge of the original messages and the other is to extract the
common message fields for aggregation. common message fields for aggregation.
3.2. PIM Assert Packing Simple Type 3.2. PIM Assert Packing Simple Type
In this type of packing, the original assert message body is used as In this type of packing, the original assert message body is used as
a record. The newly defined assert message can carry multiple assert a record. The newly defined assert message can carry multiple assert
records and identify the number of records. records and identify the number of records.
This packing method is simply extended from the original assert This packing method is simply extended from the original assert
packet, but, because the multicast service deployment often uses a packet, but, because the multicast service deployment often uses a
small number of sources and RPs, there may be a large number of small number of sources and RPs, there may be a large number of
assert records with the same metric preference or route metric assert records with the same metric preference or route metric
field, which wastes the payload of the transmitted message field, which would waste the payload of the transmitted message.
3.3. PIM Assert Packing Aggregation Type 3.3. PIM Assert Packing Aggregation Type
When the source or RP addresses, in the actual deployment of the When the source or RP addresses, in the actual deployment of the
multicast service, are very few, this type of packing will combine multicast service, are very few, this type of packing will combine
the records related to the source address or RP address in the the records related to the source address or RP address in the
assert message. assert message.
* (S, G) assert is aggregated according to the same source address, * A (S, G) assert only can contain one SPT (S, G) entry, so it can
and all SPT (S, G) entries corresponding to the source address are be aggregated according to the same source address, and then all SPT
merged into one assert record. (S, G) entries corresponding to the same source address are merged
into one assert record.
* (*, G) assert is aggregated according to the same RP address, and * A (*, G) assert may contain a (*, G) entry or a RPT (S, G) entry,
all (*, G) and RPT (S, G) entries corresponding to the RP address and both entry types actually depend on the route to the RP. So it
are merged into one assert record. can be aggregated further according to the same RP address, and then
all (*, G) and RPT (S, G) entries corresponding to the same RP
address are merged into one assert record.
This method can optimize the payload of the transmitted message by This method can optimize the payload of the transmitted message by
merging the same field content, but will add the complexity of the merging the same field content, but will add the complexity of the
packet encapsulation and parsing. packet encapsulation and parsing.
4. Packet Format 4. Packet Format
This section describes the format of new PIM messages introduced by This section describes the format of new PIM messages introduced by
this document. The messages follow the same transmission order as this document. The messages follow the same transmission order as
the messages defined in [RFC7761] the messages defined in [RFC7761]
skipping to change at page 6, line 32 skipping to change at page 7, line 10
2: indicates aggregating packing type as described in section 2.3 2: indicates aggregating packing type as described in section 2.3
3-255: reserved for future 3-255: reserved for future
4.2. PIM Assert Simple Packing Format 4.2. PIM Assert Simple Packing Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum | |PIM Ver| Type |SubType| Rsvd | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Assert Records (M) | | Reserved | Number of Assert Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Assert Record [1] . . Assert Record [1] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 7, line 15 skipping to change at page 7, line 37
. . . . . .
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Assert Record [M] . . Assert Record [M] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum
Same as [RFC7761] Section 4.9.6
Type
The new Assert Type and SubType values TBD
Number of Assert Records
The number of packed assert records. A record consists of a
single assert message body.
The format of each record is the same as the PIM assert message body The format of each record is the same as the PIM assert message body
of section 4.9.6 in [RFC7761]. of section 4.9.6 in [RFC7761].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) | | Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Metric Preference | |R| Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. PIM Assert Aggregation Packing Format 4.3. PIM Assert Aggregation Packing Format
This method also extends PIM assert packets to carry multiple This method also extends PIM assert packets to carry multiple
records. The specific assert packet format is the same as section records. The specific assert packet format is the same as section
3.2, but the records are divided into two types. 4.2, but the records are divided into two types.
The (S, G) assert records are organized by the same source address, The (S, G) assert records are organized by the same source address,
and the specific message format is: and the specific message format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) | | Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Metric Preference | |0| Metric Preference |
skipping to change at page 8, line 14 skipping to change at page 8, line 50
| Group Address 1 (Encoded-Group format) | | Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 2 (Encoded-Group format) | | Group Address 2 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address N (Encoded-Group format) | | Group Address N (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Address, Metric Preference, Metric and Reserved
Same as [RFC7761] Section 4.9.6, but the source address MUST NOT
be set to zero.
Number of Groups
The number of group addresses corresponding to the source address
field in the (S, G) assert record.
Group Address
Same as [RFC7761] Section 4.9.6, but there are multiple group
addresses in the (S, G) assert record
The (*, G) assert records are organized in the same RP address and The (*, G) assert records are organized in the same RP address and
are divided into two levels of TLVs. The first level is the group are divided into two levels of TLVs. The first level is the group
record of the same RP address, and the second level is the source record of the same RP address, and the second level is the source
record of the same multicast group address, including (*, G) and RPT record of the same multicast group address, including (*, G) and RPT
(S, G), and the specific message format is: (S, G), and the specific message format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address (Encoded-Unicast format) | | RP Address (Encoded-Unicast format) |
skipping to change at page 8, line 49 skipping to change at page 10, line 4
. Group Record [2] . . Group Record [2] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
. . . . . .
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Group Record [O] . . Group Record [O] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RP Address
The address of RP corresponding to all of the contained group
records. The format for this address is given in the encoded
unicast address in [RFC7761] Section 4.9.1
Metric Preference, Metric and Reserved
Same as [RFC7761] Section 4.9.6
Number of Group Records
The number of packed group records. A record consists of a group
address and a source address list.
The format of each group record is: The format of each group record is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) | | Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sources (P) | Reserved | | Number of Sources (P) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address 1 (Encoded-Unicast format) | | Source Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address 2 (Encoded-Unicast format) | | Source Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address P (Encoded-Unicast format) | | Source Address P (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group Address and Reserved
Same as [RFC7761] Section 4.9.6
Number of Sources
The number of source addresses corresponding to the group address
field in the group record.
Source Address
Same as [RFC7761] Section 4.9.6, but there are multiple source
addresses in the group record.
5. IANA Considerations 5. IANA Considerations
This document requests IANA to assign a registry for PIM assert This document requests IANA to assign a registry for PIM assert
packing Hello Option in the PIM-Hello Options. The assignment is packing Hello Option in the PIM-Hello Options and new PIM assert
requested permanent for IANA when this document is published as an packet type and subtype. The assignment is requested permanent for
RFC. The string TBD should be replaced by the assigned values IANA when this document is published as an RFC. The string TBD
accordingly. should be replaced by the assigned values accordingly.
6. Security Considerations 6. Security Considerations
For general PIM-SM protocol Security Considerations, see [RFC7761]. For general PIM-SM protocol Security Considerations, see [RFC7761].
TBD TBD
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 11, line 15 skipping to change at page 13, line 15
Yisong Liu Yisong Liu
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: liuyisong@huawei.com Email: liuyisong@huawei.com
Mike McBride Mike McBride
Huawei Technologies Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95055 Santa Clara, CA 95055
USA USA
Email: Michael.mcbride@huawei.com Email: michael.mcbride@futurewei.com
Toerless Eckert Toerless Eckert
Huawei Technologies Futurewei
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
USA USA
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
 End of changes. 34 change blocks. 
68 lines changed or deleted 142 lines changed or added

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