📄 rfc2102.txt
字号:
1. S-EID : The EID of the initiator of the flow.
2. T-EID : The EID of the target of the flow.
3. Flow-id : A label denoting the flow.
4. Direction : The direction of the flow - whether from the initiator
to the target (FORW) or from the target to the initiator (REVERSE)
or both (BOTH).
5. Code : Denotes whether the packet is for joining a flow
(NMFReq-Join) for leaving a flow (NMFReq-Prune).
6. Source Route : A sequence of node locators through which the packet
must travel.
Ramanathan Informational [Page 12]
RFC 2102 Nimrod Multicast Support February 1997
The processing of the NMFReq by a forwarding agent at node N is
similar to that of the unicast flow request (see [CCS96]), except for
the fact that now we provide the ability for the new flow to "splice"
onto an existing delivery tree or "un-splice" from an existing
delivery tree. Specifically,
o If the Code is NMFReq-Join then the algorithm executed by the
forwarding agent for node N is shown in Figure 1.
o If the Code is NMFReq-Prune then the algorithm is executed by the
forwarding agent at node N is shown in Figure 2.
The NMFRep packet is used to accept or reject an NMFReq-Join or
NMFReq-Prune. The packet format is the same as that for unicast flow
request. However, an NMFRep packet is generated now by the first
node N that grafts the new flow to the existing tree. This may be
different from the target of the NMFReq.
It is required that a leaf router keep track of all hosts currently
joined to the group and send a prune message only if there is no host
in the local network for the group.
The NMFReq - NMFRep exchanges constitute a procedure for joining a
multicast delivery tree (when the Code is Join) and for leaving a
multicast delivery tree (when the Code is Prune). We term these
procedures Tree-Join and Tree-Leave respectively; we shall be using
these procedures as "building-blocks" in the construction of shared
trees (section 5.3) and of source-based trees (section 5.4).
Ramanathan Informational [Page 13]
RFC 2102 Nimrod Multicast Support February 1997
begin
if the flow-id F in NMFReq-Join is in flow-list then
if T-EID in NMFReq-Join = target in flow state for F then
if Direction in NMFReq-Join is REVERSE or BOTH then
Add the node preceding N in source route to child list for F
else
discard packet
else
discard packet
else
begin
install state for F in N, i.e.,
assign parent(F) = node succeeding N in source route
assign child(F) = node preceeding N in source route
assign target(F) = T-EID in NMFReq-Join
forward NMFReq-Join to parent(F)
end
end.
Figure 1: Algorithm executed by a forwarding agent for node N when
when it receives an NMFReq-Join.
begin
if the flow-id F in NMFReq-Prune is in flow-list
then begin
delete previous hop in source route from child list for F, if exists
if child list for F is empty
then begin
delete the flow-id and state associated with it
forward to next hop in source route
end
else discard packet
end
else forward to next hop in source-route
end.
Figure 2: Algorithm executed by a forwarding agent for node N when it
receives an NMFReq-Prune.
Ramanathan Informational [Page 14]
RFC 2102 Nimrod Multicast Support February 1997
5.2.1 An Example
An example of how a tree is joined is given here with the help of
Figure 3. In the figure, bold lines indicate an existing tree.
Representative R on behalf of host H joins the tree by sending an
NMFJoin-Req towards a target T. When used in the shared tree mode,
the target is the RP and when used in the source tree mode, it is the
source (root) of the multicast tree. Suppose that a host H wants to
join the multicast tree. The following steps are executed :
Step 1. A representative R of H queries the route agent for a route
from T to R. It obtains the route T - C- B - A - R. It builds a
NMFJoin-Req packet with source route as R, A, B, C, T and flow
as F forwards it to A.
Step 2. A looks for flow F in its installed flow database and
doesn't find it. It installs state for F (makes R a child and
B a parent in the multicast tree) and sends the NMFJoin-Req packet
to B.
Step 3. B looks for flow F in its installed flow database and finds it.
It adds B to its child list and constructs an NMFJoin-Rep packet and
sends it to A.
Step 4. A forwards the packet to R and the tree joining is complete.
Branch B-A-R is now added to the tree.
Ramanathan Informational [Page 15]
RFC 2102 Nimrod Multicast Support February 1997
5.3 Establishing a Shared Tree
There are two parts to establishing a shared tree - the receiver-to-
RP communication wherein the receiver joins the delivery tree rooted
at RP and the sender-to-RP communication wherein the RP joins the
delivery tree rooted at the sender.
T
+---+
| |\
+---+ \
/ \
/ \
C / \ X
+---+ +---+
| | | |
+---+ +---+
\
\
\
R join-req join-req \ B
+---+ - - - - -> +---+ - - - - -> +---+
| |<------------| |<-----------| |
+---+ join-rep +---+ join-rep +---+
| A \
| \
| \ Y
( ) +---+
H | |
+---+
Figure 3: Illustration for the example describing joining an existing
multicast tree.
Receiver-RP Communications: When an endpoint wishes to join a
multicast group G, the endpoint representative obtains the Rendezvous
Point EID for G. We assume that the association database contains
such a mapping. For details on how the association database query is
implemented, please refer [CCS96].
The representative also obtains the flow-id to be used for the flow.
The flow-id is constructed as the tuple (RP-EID, G) or an equivalent
thereof. Note that the flow-id must be unique to the particular
multicast flow. This is not the only method or perhaps even the best
method for obtaining a flow id. Alternate methods for obtaining the
flow-id are discussed in section 5.5.
Ramanathan Informational [Page 16]
RFC 2102 Nimrod Multicast Support February 1997
The representative then initiates a Tree-Join procedure.
The NMFReq packet fields are as follows:
o S-EID : The EID of the endpoint wishing to join.
o T-EID : The RP EID (obtained from the Association Database).
o Flow-id : The flow-id for this group (obtained as mentioned
above).
o Direction : REVERSE (from the RP to the receiving endpoint).
o Code : Join.
o Source Route : Reverse of the route obtained from the map agent
for a query "from RP-EID to Receiver-EID".
At the first node already containing this Flow-id or the RP, an
NMFRep packet is generated. The S-EID, T-EID, Direction and Flow-id
fields are copied from the NMFReq packet and the Code is set to
Join-Accept or Join-Refuse as the case may be. The source route is
reversed from the NMFReq packet.
Sender-RP Communications: When an endpoint wishes to send to a
multicast group G, the endpoint representative obtains the Rendezvous
Point EID for G. We assume that the association database contains
such a mapping. For details on how the association database query is
implemented, please refer [CCS96].
The representative also obtains the flow-id to be used for the flow.
The flow-id is constructed as the tuple (Sender-EID, G) or an
equivalent thereof. Note that the flow-id must be unique to the
particular multicast flow. This is not the only method or perhaps
even the best method for obtaining a flow id. Alternate methods for
obtaining the flow-id are discussed in section 5.5.
The representative then sends a RP-Register Message to the RP. This
register message is equivalent to the PIM-Register described in
[DEF+94b]. The RP-Register message contains the group G and the
flow-id (obtained as discussed above) and the sender EID.
The RP then initiates a Tree-Join with the Sender EID as the target.
The NMFReq fields are as follows :
o S-EID : RP-EID.
o T-EID : Sender EID (copied from RP-Register Message).
Ramanathan Informational [Page 17]
RFC 2102 Nimrod Multicast Support February 1997
o Flow-id : The flow-id field from RP-Register Message.
o Code : Join.
o Direction : REVERSE.
o Source Route : Reverse of the route obtained from map agent
query "from Sender-EID to RP-EID".
The NMFRep fields are obvious.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -