⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2102.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 4 页
字号:

   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 + -