< draft-ietf-msdp-spec-12.txt   draft-ietf-msdp-spec-13.txt >
Network Working Group David Meyer (Editor) Network Working Group David Meyer (Editor)
INTERNET DRAFT Bill Fenner (Editor) INTERNET DRAFT Bill Fenner (Editor)
Category Standards Track Category Standards Track
September, 2001 November, 2001
Multicast Source Discovery Protocol (MSDP) Multicast Source Discovery Protocol (MSDP)
<draft-ietf-msdp-spec-12.txt> <draft-ietf-msdp-spec-13.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 17 skipping to change at page 3, line 17
When an RP in a PIM-SM domain first learns of a new sender, e.g. via When an RP in a PIM-SM domain first learns of a new sender, e.g. via
PIM register messages, it constructs a "Source-Active" (SA) message PIM register messages, it constructs a "Source-Active" (SA) message
and sends it to its MSDP peers. The SA message contains the following and sends it to its MSDP peers. The SA message contains the following
fields: fields:
o Source address of the data source. o Source address of the data source.
o Group address the data source sends to. o Group address the data source sends to.
o IP address of the RP. o IP address of the RP.
Note that an RP that isn't a DR on a shared network SHOULD NOT Note that an RP that isn't a DR on a shared network SHOULD NOT
originate SA's for directly connected sources on that shared network. originate SA's for directly connected sources on that shared network;
it should only originate in response to receiving Register messages
from the DR.
Each MSDP peer receives and forwards the message away from the RP Each MSDP peer receives and forwards the message away from the RP
address in a "peer-RPF flooding" fashion. The notion of peer-RPF address in a "peer-RPF flooding" fashion. The notion of peer-RPF
flooding is with respect to forwarding SA messages. The Multicast RPF flooding is with respect to forwarding SA messages. The Multicast RPF
Routing Information Base (MRIB) is examined to determine which peer Routing Information Base (MRIB) is examined to determine which peer
towards the originating RP of the SA message is selected. Such a peer towards the originating RP of the SA message is selected. Such a peer
is called an "RPF peer". See section 14 for the details of peer-RPF is called an "RPF peer". See section 14 for the details of peer-RPF
forwarding. forwarding.
If the MSDP peer receives the SA from a non-RPF peer towards the If the MSDP peer receives the SA from a non-RPF peer towards the
originating RP, it will drop the message. Otherwise, it forwards the originating RP, it will drop the message. Otherwise, it forwards the
message to all its MSDP peers (except the one from which it received message to all its MSDP peers (except the one from which it received
the SA message). the SA message).
When an MSDP peer which is also an RP for its own domain receives a When an MSDP peer which is also an RP for its own domain receives a
new SA message, it determines if it has any group members interested new SA message, it determines if there are any group members within
in the group which the SA message describes. That is, the RP checks the domain interested in any group described by an (S,G) entry within
for a (*,G) entry with a non-empty outgoing interface list; this the SA message. That is, the RP checks for a (*,G) entry with a non-
implies that the domain is interested in the group. In this case, the empty outgoing interface list; this implies that some system in the
RP triggers a (S,G) join event towards the data source as if a domain is interested in the group. In this case, the RP triggers a
Join/Prune message was received addressed to the RP itself. This sets (S,G) join event towards the data source as if a Join/Prune message
up a branch of the source-tree to this domain. Subsequent data was received addressed to the RP itself. This sets up a branch of the
packets arrive at the RP which are forwarded down the shared-tree source-tree to this domain. Subsequent data packets arrive at the RP
inside the domain. If leaf routers choose to join the source-tree via this tree branch, and are forwarded down the shared-tree inside
they have the option to do so according to existing PIM-SM the domain. If leaf routers choose to join the source-tree they have
conventions. Finally, if an RP in a domain receives a PIM Join the option to do so according to existing PIM-SM conventions.
message for a new group G, the RP SHOULD trigger a (S,G) join event Finally, if an RP in a domain receives a PIM Join message for a new
for each SA for that group in its cache. group G, the RP SHOULD trigger a (S,G) join event for each active
(S,G) for that group in its SA cache.
This procedure has been affectionately named flood-and-join because This procedure has been affectionately named flood-and-join because
if any RP is not interested in the group, they can ignore the SA if any RP is not interested in the group, they can ignore the SA
message. Otherwise, they join a distribution tree. message. Otherwise, they join a distribution tree.
7. Caching 7. Caching
A MSDP speaker MUST cache SA messages. Caching allows pacing of MSDP A MSDP speaker MUST cache SA messages. Caching allows pacing of MSDP
messages as well as reducing join latency for new receivers of a messages as well as reducing join latency for new receivers of a
group G at an originating RP which has existing MSDP (S,G) state. In group G at an originating RP which has existing MSDP (S,G) state. In
addition, caching greatly aids in diagnosis and debugging of various addition, caching greatly aids in diagnosis and debugging of various
problems. problems.
8. Timers 8. Timers
The main timers for MSDP are: SA-Advertisement-Timer, SA-Hold-Down- The main timers for MSDP are: SA-Advertisement-Timer, SG-Rate-Limit-
Timer, SA Cache Entry timer, KeepAlive timer, ConnectRetry and Peer Timer, SA Cache Entry timer, KeepAlive timer, ConnectRetry and Peer
Hold Timer. Each is considered below. Hold Timer. Each is considered below.
8.1. SA-Advertisement-Timer 8.1. SA-Advertisement-Timer
RPs which originate SA messages do so periodically as long as there RPs which originate SA messages do so periodically as long as there
is data being sent by the source. There is one SA-Advertisement-Timer is data being sent by the source. There is one SA-Advertisement-Timer
covering the sources that an RP may advertise. [SA-Advertisement- covering the sources that an RP may advertise. [SA-Advertisement-
Period] MUST be 180 seconds. An RP MUST not send more than one Period] MUST be 60 seconds. An RP MUST not send more than one
periodic SA message for a given (S,G) within an SA Advertisement periodic SA message for a given (S,G) within an SA Advertisement
interval. Originating periodic SA messages is required to keep interval. Originating periodic SA messages is required to keep
announcements alive in caches. Finally, an originating RP SHOULD announcements alive in caches. Finally, an originating RP SHOULD
trigger the transmission of an SA message as soon as it receives data trigger the transmission of an SA message as soon as it receives data
from an internal source for the first time. from an internal source for the first time.
8.2. SA-Advertisement-Timer Processing 8.2. SA-Advertisement-Timer Processing
An RP MUST spread the generation of periodic SA messages over its An RP MUST spread the generation of periodic SA messages (i.e.
reporting interval (i.e. SA-Advertisement-Period). An RP starts the messages advertising the active sources for which it is the RP) over
SA-Advertisement-Timer when the MSDP process is configured. When the its reporting interval (i.e. SA-Advertisement-Period). An RP starts
timer expires, an RP resets the timer to [SA-Advertisement-Period] the SA-Advertisement-Timer when the MSDP process is configured. When
seconds, and begins the advertisement of its active sources. Active the timer expires, an RP resets the timer to [SA-Advertisement-
sources are advertised in the following manner: An RP packs its Period] seconds, and begins the advertisement of its active sources.
active sources into an SA message until the largest MSDP packet that Active sources are advertised in the following manner: An RP packs
can be sent is built or there are no more sources, and then sends the its active sources into an SA message until the largest MSDP packet
message. This process is repeated periodically within the SA- that can be sent is built or there are no more sources, and then
Advertisement-Period in such a way that all of the RP's sources are sends the message. This process is repeated periodically within the
advertised. Note that since MSDP is a periodic protocol, an SA-Advertisement-Period in such a way that all of the RP's sources
are advertised. Note that since MSDP is a periodic protocol, an
implemenation SHOULD send all cached SA messages when a connection is implemenation SHOULD send all cached SA messages when a connection is
established. Finally, the timer is deleted when the MSDP process is established. Finally, the timer is deleted when the MSDP process is
deconfigured. deconfigured.
8.3. SA Cache Timeout (SA-State Timer) 8.3. SA Cache Timeout (SA-State Timer)
Each entry in an SA Cache has an associated SA-State Timer. A Each entry in an SA Cache has an associated SA-State Timer. A
(S,G)-SA-State-Timer is started when an (S,G)-SA message is initially (S,G)-SA-State-Timer is started when an (S,G)-SA message is initially
received by a MSDP peer. The timer is reset to [SA-State-Period] if received by a MSDP peer. The timer is reset to [SG-State-Period] if
another (S,G)-SA message is received before the (S,G)-SA-State Timer another (S,G)-SA message is received before the (S,G)-SA-State Timer
expires. [SA-State-Period] MUST NOT be less than [SA-Advertisement- expires. The timer is reset whether or not the (S,G) entry's SG-
Period] + [SA-Hold-Down-Period]. Rate-Limit timer is running. [SG-State-Period] MUST NOT be less than
[SA-Advertisement-Period] + [SA-Hold-Down-Period].
8.4. SA-Hold-Down Timer 8.4. SG-Rate-Limit Timer
When an SA message is received which creates (S,G) state, the The SG-Rate-Limit Timer is a per-(S,G) timer which is used to limit
(S,G)-SA message will be forwarded if the peer-RPF check succeeds. If possible SA storms. After an SA message passes the peer-RPF check,
the peer-RPF check succeeds and the (S,G)-SA message is not already the SG-Rate-Limit timer for each (S,G) in the message is checked. If
in the SA cache, then the (S,G)-SA-Hold-Down timer is set to [SA- the SG-Rate-Limit timer is running for a given (S,G), it is removed
Hold-Down-Period] seconds. When an (S,G)-SA message is received and from the message before forwarding. If this process causes the
an (S,G) entry already exists, the message is forwarded only if the message to become empty, the empty message is discarded.
(S,G)-SA-Hold-Down timer is not running. [SA-Hold-Down-Period] SHOULD
be set to 30 seconds. When an SA message is forwarded, the SG-Rate-Limit timer for each
(S,G) mentioned in the message is set to [SG-Rate-Limit-Period]
seconds. Note that this sequence means that the SG-Rate-Limit timer
will never be reset if it is running, since any (S,G) whose timer was
running was removed from the forwarded message; it acts as a "one-
shot" timer.
[SG-Rate-Limit-Period] SHOULD be set to 30 seconds, and MUST NOT be
greater than [SA-Advertisement-Period].
8.5. Peer Hold Timer 8.5. Peer Hold Timer
If a system has not received any MSDP message within the period If a system has not received any MSDP message within the period
specified by the Hold Timer, then a Notification message with Hold specified by the Hold Timer, then a Notification message with Hold
Timer Expired Error Code MUST be sent and the MSDP connection MUST be Timer Expired Error Code MUST be sent and the MSDP connection MUST be
closed. [HoldTime-Period] MUST be at least three seconds. The closed. [HoldTime-Period] MUST be at least three seconds. The
recommended value for [HoldTime-Period] is 90 seconds. recommended value for [HoldTime-Period] is 90 seconds.
The Hold Timer is initialized to [HoldTime-Period] when the peer's The Hold Timer is initialized to [HoldTime-Period] when the peer's
skipping to change at page 6, line 15 skipping to change at page 6, line 25
Finally, the KeepAlive timer is deleted when the peer's transport Finally, the KeepAlive timer is deleted when the peer's transport
connection is closed. connection is closed.
[KeepAlive-Period] MUST be less than [HoldTime-Period], and MUST be [KeepAlive-Period] MUST be less than [HoldTime-Period], and MUST be
at least one second. The recommended value for [KeepAlive-Period] is at least one second. The recommended value for [KeepAlive-Period] is
75 seconds. 75 seconds.
8.7. ConnectRetry Timer 8.7. ConnectRetry Timer
The ConnectRetry timer is used by an MSDP peer to transition from The ConnectRetry timer is used by the MSDP peer with the lower IP
INACTIVE to CONNECTING states. There is one timer per peer, and the address to transition from INACTIVE to CONNECTING states. There is
[ConnectRetry-Period] SHOULD be set to 30 seconds. The timer is one timer per peer, and the [ConnectRetry-Period] SHOULD be set to 30
initialized to [ConnectRetry-Period] when an MSDP speaker attempts to seconds. The timer is initialized to [ConnectRetry-Period] when an
actively open a TCP connection to its peer (see section 15, event E2, MSDP speaker attempts to actively open a TCP connection to its peer
action A2 ). When the timer expires, the peer retries the connection (see section 15, event E2, action A2 ). When the timer expires, the
and the timer is reset to [ConnectRetry-Period]. It is deleted if peer retries the connection and the timer is reset to [ConnectRetry-
either the connection transitions into ESTABLISHED state or the peer Period]. It is deleted if either the connection transitions into
is deconfigured. ESTABLISHED state or the peer is deconfigured.
9. Intermediate MSDP Peers 9. Intermediate MSDP Peers
Intermediate MSDP speakers do not originate periodic SA messages on Intermediate MSDP speakers do not originate periodic SA messages on
behalf of sources in other domains. In general, an RP MUST only behalf of sources in other domains. In general, an RP MUST only
originate an SA for a source which would register to it, and ONLY RPs originate an SA for a source which would register to it, and ONLY RPs
may originate SA messages. may originate SA messages.
10. SA Filtering and Policy 10. SA Filtering and Policy
skipping to change at page 8, line 9 skipping to change at page 8, line 17
MSDP is not limited to deployment across different routing domains. MSDP is not limited to deployment across different routing domains.
It can be used within a routing domain when it is desired to deploy It can be used within a routing domain when it is desired to deploy
multiple RPs for the same group ranges. As long as all RPs have a multiple RPs for the same group ranges. As long as all RPs have a
interconnected MSDP topology, each can learn about active sources as interconnected MSDP topology, each can learn about active sources as
well as RPs in other domains. well as RPs in other domains.
14. MSDP Peer-RPF Forwarding 14. MSDP Peer-RPF Forwarding
The MSDP Peer-RPF Forwarding rules are used for forwarding SA The MSDP Peer-RPF Forwarding rules are used for forwarding SA
messages throughout an MSDP enabled internet. Unlike the RPF check messages throughout an MSDP enabled internet. Unlike the RPF check
used when forwarding data packets, the Peer-RPF check is against the used when forwarding data packets, which generally compares the
RP address carried in the SA message. packet's source address against the interface upon which the packet
was received, the Peer-RPF check compares the RP address carried in
the SA message against the MSDP peer from which the message was
received.
14.1. Definitions 14.1. Definitions
The following definitions are used in the description of the Peer-RPF The following definitions are used in the description of the Peer-RPF
Forwarding Rules: Forwarding Rules:
14.1.1. Multicast RPF Routing Information Base (MRIB) 14.1.1. Multicast RPF Routing Information Base (MRIB)
The MRIB is the multicast topology table. It is typically derived The MRIB is the multicast topology table. It is typically derived
from the unicast routing table or from other routing protocols such from the unicast routing table or from other routing protocols such
as multi-protocol BGP [RFC2283]. as multi-protocol BGP [RFC2283].
14.1.2. RPF Route 14.1.2. Peer-RPF Route
The RPF route is the route that the MRIB chooses for a given address. The Peer-RPF route is the route that the MRIB chooses for a given
The RPF route for a SA's originating RP is used to select the peer address. The Peer-RPF route for a SA's originating RP is used to
from which the SA is accepted. select the peer from which the SA is accepted.
14.2. Peer-RPF Forwarding Rules 14.2. Peer-RPF Forwarding Rules
An SA message originated by R and received by X from N is An SA message originated by R and received by X from N is
accepted if N is the peer-RPF neighbor for X, and is discarded accepted if N is the peer-RPF neighbor for X, and is discarded
otherwise. otherwise.
MPP(R,N) MP(N,X) MPP(R,N) MP(N,X)
R ---------....-------> N ------------------> X R ---------....-------> N ------------------> X
SA(S,G,R) SA(S,G,R) SA(S,G,R) SA(S,G,R)
Where MPP(R,N) is an MSDP peering path (zero or more MSDP MP(N,X) is an MSDP peering between N and X. MPP(R,N) is
peers) between R and N. SA(S,G,R) is an SA message for source an MSDP peering path (zero or more MSDP peers) between R
S on group G originated by an RP R. MP(N,X) is an MSDP and N, e.g. MPP(R,N) = MP(R, A) + MP(A, B) + MP(B, N).
peering between N and X. SA(S,G,R) is an SA message for source S on group G originated
by an RP R.
The peer-RPF neighbor is chosen deterministically, using the The peer-RPF neighbor P is chosen deterministically, using the
first of the following rules that matches. In particular, first of the following rules that matches. In particular,
N is the RPF neighbor of X with respect to R if P is the RPF neighbor of X with respect to R if
(i). N == R (X has an MSDP peering with R). (i). P == R (X has an MSDP peering with R).
(ii). N is the BGP NEXT_HOP of the active RPF route (ii). P is the BGP NEXT_HOP of the Peer-RPF route
for R. for R.
(iii). The active RPF route for R is learned through a (iii). The Peer-RPF route for R is learned through a
distance-vector or path-vector routing protocol distance-vector or path-vector routing protocol
(e.g. BGP, RIP, DVMRP) and N is the neighbor that (e.g. BGP, RIP, DVMRP) and P is the neighbor that
advertised the active RPF route for R if the advertised the Peer-RPF route for R if the
route was learned via a distance-vector or route was learned via a distance-vector or
path-vector protocol, or N is the IGP next hop path-vector protocol, or P is the IGP next hop
for if R was learned via a link-state protocol. for R if learned via a link-state protocol.
(iv). N resides in an AS that is in the AS_PATH of the active (iv). P resides in an AS that is in the AS_PATH of the
RPF route for R, and N has the highest IP address among Peer-RPF route for R, and P has the highest IP address among
the MSDP peers that reside in ASs in that AS_PATH. the MSDP peers that reside in ASs in that AS_PATH.
(v). N is configured as the static RPF-peer for R. (v). P is configured as the static RPF-peer for R.
When an SA message with RP R is received from neighbor N, it is
discarded unless N == P as determined above.
14.3. MSDP static RPF-peer semantics 14.3. MSDP static RPF-peer semantics
If none of the rules (i) - (iv) are able to determine an RPF peer for If none of the rules (i) - (iv) are able to determine an RPF peer for
R, a longest-match lookup is performed in the static RPF peer table. R, a longest-match lookup is performed in the static RPF peer table.
This table MUST be able to contain a default entry, and SHOULD be This table MUST be able to contain a default entry, and SHOULD be
able to contain prefix or per-host (RP) entries. This table able to contain prefix or per-host (RP) entries. This table
statically maps RP addresses to peers, and allows configuration of statically maps RP addresses to peers, and allows configuration of
topology that is e.g. unknown to the MRIB. topology that is e.g. unknown to the multicast topology gathering
protocol.
The result of the longest-match lookup of an RP address R in the The result of the longest-match lookup of an RP address R in the
static RPF peer table is an MSDP peer, which is the RPF neighbor for static RPF peer table is an MSDP peer, which is the RPF neighbor for
R. R.
14.4. MSDP mesh-group semantics 14.4. MSDP mesh-group semantics
A MSDP mesh-group is a operational mechanism for reducing SA A MSDP mesh-group is a operational mechanism for reducing SA
flooding, typically in an intra-domain setting. In particular, when flooding, typically in an intra-domain setting. In particular, when
some subset of a domain's MSDP speakers are fully meshed, then can be some subset of a domain's MSDP speakers are fully meshed, then can be
skipping to change at page 12, line 13 skipping to change at page 12, line 13
configuration to cause SA looping. configuration to cause SA looping.
15. MSDP Connection State Machine 15. MSDP Connection State Machine
MSDP uses TCP as its transport protocol. In a peering relationship, MSDP uses TCP as its transport protocol. In a peering relationship,
one MSDP peer listens for new TCP connections on the well-known port one MSDP peer listens for new TCP connections on the well-known port
639. The other side makes an active connect to this port. The peer 639. The other side makes an active connect to this port. The peer
with the higher IP address will listen. This connection establishment with the higher IP address will listen. This connection establishment
algorithm avoids call collision. Therefore, there is no need for a algorithm avoids call collision. Therefore, there is no need for a
call collision procedure. It should be noted, however, that the call collision procedure. It should be noted, however, that the
disadvantage of this approach is that it may result in longer startup disadvantage of this approach is that the startup time depends
times at the passive side. completely upon the active side and its connect retry timer; the
passive side cannot cause the connection to be established.
An MSDP peer starts in the DISABLED state. MSDP peers establish An MSDP peer starts in the DISABLED state. MSDP peers establish
peering sessions according to the following state machine: peering sessions according to the following state machine:
--------------->+----------+ --------------->+----------+
/ | DISABLED |<---------- / | DISABLED |<----------
| ------>+----------+ \ | ------>+----------+ \
| / |E1->A1 | | / |E1->A1 |
| | | | | | | |
| | V |E7->A7 | | V |E7->A7
skipping to change at page 14, line 29 skipping to change at page 14, line 29
state, they do not cause a state transition. Appropriate actions are state, they do not cause a state transition. Appropriate actions are
listed for each event. listed for each event.
*) KeepAlive timer expired: *) KeepAlive timer expired:
-> Send KeepAlive TLV -> Send KeepAlive TLV
-> Set KeepAlive timer to [KeepAlive-Period] -> Set KeepAlive timer to [KeepAlive-Period]
*) KeepAlive TLV received: *) KeepAlive TLV received:
-> Set Hold Timer to [HoldTime-Period] -> Set Hold Timer to [HoldTime-Period]
*) Source-Active TLV received: *) Source-Active TLV received:
-> Set Hold Timer to [HoldTime-Period] -> Set Hold Timer to [HoldTime-Period]
-> Run Peer-RPF Forwarding algorithm (consider SA-Hold-Down -> Run Peer-RPF Forwarding algorithm (consider SG-Rate-Limit
Timer and SA-State Timer) Timer and SA-State Timer)
-> Set KeepAlive timer to [KeepAlive-Period] for those peers -> Set KeepAlive timer to [KeepAlive-Period] for those peers
the Source-Active TLV is forwarded to the Source-Active TLV is forwarded to
-> Send information to PIM-SM -> Send information to PIM-SM
-> Store information in cache -> Store information in cache
*) Source-Active Request TLV received: *) Source-Active Request TLV received:
-> Set Hold Timer to [HoldTime-Period] -> Set Hold Timer to [HoldTime-Period]
-> If SA-Requests are accepted, send Source-Active Response -> If SA-Requests are accepted, send Source-Active Response
TLV and set KeepAlive timer to [KeepAlive-Period] TLV and set KeepAlive timer to [KeepAlive-Period]
*) Source-Active Response TLV received: *) Source-Active Response TLV received:
skipping to change at page 15, line 22 skipping to change at page 15, line 22
-> Start periodic transmission of Source-Active TLV(s) -> Start periodic transmission of Source-Active TLV(s)
-> Set KeepAlive timer to [KeepAlive-Period] each time a -> Set KeepAlive timer to [KeepAlive-Period] each time a
Source-Active TLV is sent Source-Active TLV is sent
*) MSDP learns of a new active internal source (e.g. PIM-SM *) MSDP learns of a new active internal source (e.g. PIM-SM
register received for a new source): register received for a new source):
-> Send Source-Active TLV -> Send Source-Active TLV
-> Set KeepAlive timer to [KeepAlive-Period] -> Set KeepAlive timer to [KeepAlive-Period]
*) Source-Active Request triggered (event not specified here): *) Source-Active Request triggered (event not specified here):
-> Send Source-Active Request TLV -> Send Source-Active Request TLV
-> Set KeepAlive timer to [KeepAlive-Period] -> Set KeepAlive timer to [KeepAlive-Period]
*) SA-State-Timer expired (one timer per cache entry): *) SG-State-Timer expired (one timer per cache entry):
-> Implementation specific, typically mark the cache entry for -> Implementation specific, typically mark the cache entry for
deletion deletion
16. Packet Formats 16. Packet Formats
MSDP messages will be encoded in TLV format. If an implementation MSDP messages will be encoded in TLV format. If an implementation
receives a TLV that has length that is longer than expected, the TLV receives a TLV that has length that is longer than expected, the TLV
SHOULD be accepted. Any additional data SHOULD be ignored. SHOULD be accepted. Any additional data SHOULD be ignored.
16.1. MSDP TLV format: 16.1. MSDP TLV format:
skipping to change at page 16, line 24 skipping to change at page 16, line 24
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value .... | | Type | Length | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits) Type (8 bits)
Describes the format of the Value field. Describes the format of the Value field.
Length (16 bits) Length (16 bits)
Length of Type, Length, and Value fields in octets. Length of Type, Length, and Value fields in octets.
minimum length required is 4 octets, except for Minimum length required is 4 octets, except for
Keepalive messages. The maximum TLV length is 1400. Keepalive messages. The maximum TLV length is 9192.
Value (variable length) Value (variable length)
Format is based on the Type value. See below. The length of Format is based on the Type value. See below. The length of
the value field is Length field minus 3. All reserved fields the value field is Length field minus 3. All reserved fields
in the Value field MUST be transmitted as zeros and ignored on in the Value field MUST be transmitted as zeros and ignored on
receipt. receipt.
16.2. Defined TLVs 16.2. Defined TLVs
The following TLV Types are defined: The following TLV Types are defined:
skipping to change at page 17, line 49 skipping to change at page 17, line 49
packet follows and y is the length of the total length field packet follows and y is the length of the total length field
of the IPv4 header encapsulated. If there are multiple SA TLVs of the IPv4 header encapsulated. If there are multiple SA TLVs
in a message, and data is also included, y must be 0 in all SA in a message, and data is also included, y must be 0 in all SA
TLVs except the last one and the last SA TLV must reflect the TLVs except the last one and the last SA TLV must reflect the
source and destination addresses in the IP header of the source and destination addresses in the IP header of the
encapsulated data. encapsulated data.
Entry Count Entry Count
Is the count of z entries (note above) which follow the RP Is the count of z entries (note above) which follow the RP
address field. This is so multiple (S,G)s from the same domain address field. This is so multiple (S,G)s from the same domain
can be encoded efficiently for the same RP address. can be encoded efficiently for the same RP address. An
SA message containing encapsulated data typically has an
entry count of 1 (i.e. only contains a single entry, for
the (S,G) representing the encapsulated packet).
RP Address RP Address
The address of the RP in the domain the source has become The address of the RP in the domain the source has become
active in. active in.
Reserved Reserved
The Reserved field MUST be transmitted as zeros and MUST be The Reserved field MUST be transmitted as zeros and MUST be
ignored by a receiver. ignored by a receiver.
Sprefix Len Sprefix Len
skipping to change at page 22, line 30 skipping to change at page 22, line 30
17.1. Message Header Error Handling 17.1. Message Header Error Handling
All errors detected while processing the Message Header are indicated All errors detected while processing the Message Header are indicated
by sending the Notification message with Error Code Message Header by sending the Notification message with Error Code Message Header
Error. The Error Subcode describes the specific nature of the error. Error. The Error Subcode describes the specific nature of the error.
The Data field contains the erroneous Message (including the message The Data field contains the erroneous Message (including the message
header). header).
If the Length field of the message header is less than 4 or greater If the Length field of the message header is less than 4 or greater
than 1400, or the length of a KeepAlive message is not equal to 3, than 9192, or the length of a KeepAlive message is not equal to 3,
then the Error Subcode is set to Bad Message Length. then the Error Subcode is set to Bad Message Length.
If the Type field of the message header is not recognized, then the If the Type field of the message header is not recognized, then the
Error Subcode is set to Bad Message Type. Error Subcode is set to Bad Message Type.
17.2. SA-Request Error Handling 17.2. SA-Request Error Handling
The SA-Request Error code is used to signal the receipt of a SA The SA-Request Error code is used to signal the receipt of a SA
request at a MSDP peer when an invalid group address requested. request at a MSDP peer when an invalid group address requested.
 End of changes. 32 change blocks. 
81 lines changed or deleted 106 lines changed or added

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