rfc2490.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,411 行 · 第 1/5 页

RFC 2490                 IP Multicast with RSVP             January 1999


3.3.2 Host description

   The host model built using OPNET has a layered structure. Different
   from the OPNET layers (Network, Node and Process layer) that describe
   the network at different levels, protocol stack elements are
   implemented at OPNET nodes. Figure 3 shows the node level structure
   of a FDDI host.

                      [Figure 3: Node Level of Host]

   a. MAC queue node: The MAC interfaces on one side to the physical
   layer through the transmitter (phy_tx) and receiver (phy_rx) and also
   provides services to the IP layer.  Use of ring bandwidth is
   controlled through a timed token rotation protocol, wherein hosts
   must receive a token and meet with a set of timing and priority
   criteria before transmitting frames.  When a frame arrives at the MAC
   node, the node performs one of the following actions:

     1. If the owner of the frame is this MAC, the MAC layer destroys
        the frame since the frame has finished circulating through the
        FDDI ring.
     2. if the frame is destined for this host, the MAC layer makes a
        copy of the frame, decapsulates the frame and sends the
        descapsulated frame (packet) to the IP layer.  The original
        frame is transmitted to the next host in the FDDI ring
     3. if the owner of the frame is any other host and the frame is not
        destined for this host, the frame is forwarded to the adjacent
        host.

   b. ADDR_TRANS processor node: The next layer above the MAC layer is
   the addr_trans processor node. This layer provides service to the IP
   layer by carrying out the function of translating the IP address to
   physical interface address.  This layer accepts packets from the IP
   layer with the next node information, maps the next node information
   to a physical address and forwards the packet for transmission.  This
   service is required only in one direction from the IP layer to the
   MAC layer.  Since queuing is not done at this level, a processor node
   is used to accomplish the address translation function, from IP to
   MAC address (ARP).

   c. IP queue node: Network routing/forwarding in the hierarchy is
   implemented here. IP layer provides service for the layers above
   which are the different higher level protocols by utilizing the
   services provided by the MAC layer.  For packets arriving from the
   MAC layer, the IP layer decapsulates the packet and forwards the
   information to an upper layer protocol based upon the value of the
   protocol ID in the IP header.  For packets arriving from upper layer
   protocols,  the IP layer obtains the destination address,  calculates



Pullen, et. al.              Informational                      [Page 6]

RFC 2490                 IP Multicast with RSVP             January 1999


   the next node address from the routing table, encapsulates it with a
   IP header and forwards the packet to the addr_trans node with the
   next node information.

   The IP node is a queue node. It is in this layer that packets incur
   delay which simulates the processing capability of a host and
   queueing for use of the outgoing link.  A packet arrival to the IP
   layer will be queued and experience delay when it finds another
   packet already being transmitted, plus possibly other packets queued
   for transmission.  The packets arriving at the IP layer are queued
   and operate with a first-in first-out (FIFO) discipline.  The queue
   size, service rate of the IP layer are both promoted attributes,
   specified at the simulation run level by the environment file.

   d. IGMP processor node: The models described above are standard
   components available in OPNET libraries.  We have added to these the
   host multicast protocol model IGMP_host, the router multicast model
   IGMP_gwy, and the unicast best-effort protocol model UBE.

   The IGMP_host node (Figure 4) is a process node.  Packets are not
   queued in this layer.  IGMP_host provides unique group management
   services for the multicast applications utilizing the services
   provided by the IP layer. IGMP_host maintains a single table which
   consists of group membership information of the application above the
   IGMP layer.  The function performed by the IGMP_host layer depends
   upon the type of the packet received and the source of the packet.

                     [Figure 4: IGMP process on hosts]

   The IGMP_host layer expects certain type of packets from the
   application layer and from the network:

   1. Accept join group requests from the application layer (which can
      be one or more applications):  IGMP_host maintains a table which
      consists of the membership information for each group.  When a
      application sends a  join request,  it requests to join a specific
      group N.  The membership information is updated.  This new group
      membership information has to be conveyed to the nearest router
      and to the MAC layer.  If the IGMP_host is already a member ofthis
      group (i.e. if another application above the IGMP_host is a member
      of the group N), the IGMP_host does not have to send a message to
      the router or indicate to the MAC layer.  If the IGMP_host is not
      a member currently,  the IGMP_host generates a join request for
      the group N (this is called a "response" in RFC 1112) and forwards
      it to the IP layer to be sent to the nearest router.  In addition
      the IGMP_host also conveys this membership information to the MAC
      layer interfacing to the physical layer through the OPNET
      "statistic wire" connected from the IGMP_host to the MAC layer, so



Pullen, et. al.              Informational                      [Page 7]

RFC 2490                 IP Multicast with RSVP             January 1999


      that the MAC layer knows the membership information immediately
      and begins to accept the frames destined for the group N. (An
      OPNET statistic wire is a virtual path to send information between
      OPNET models.)
   2. Accept queries arriving from the nearest router and send responses
      based on the membership information in the multicast table at the
      IGMP_host layer:  A query is a message from a router inquiring
      each host on the router's interface about group membership
      information. When the IGMP_host receives a query, it looks up the
      multicast group membership table, to determine if any of the
      host's applications are registered for any  group.  If any
      registration exists, the IGMP_host schedules an event to generate
      a response after a random amount of time corresponding to each
      active group.  The Ethernet example in Figure 5 and the
      description in the following section describes the scenario.

                   ---------------------------------------
                        |        |         |         |
                        |        |         |         |
                      +---+    +---+     +---+     +---+
                      | H1|    | H2|     | H3|     | R |
                      +---+    +---+     +---+     +---+

           Figure 5: An Ethernet example of IGMP response schedule

      The router R interfaces with the subnet on one interface I1 and to
      reach the hosts.  To illustrate this let us assume that hosts H1
      and H3 are members of group N1 and H2 is a  member of group N2.
      When the router sends a query, all the hosts receive the query at
      the same time t0.  IGMP_host in H1 schedules an event to generate
      a response at a randomly generated time t1 (t1 >= t0) which will
      indicate the host H1 is a member of group N1.  Similarly H2 will
      schedule an event to generate a response at t2 (t2 >= t0)to
      indicate membership in group N2 and H3 at t3 (t3 >= t0) to
      indicate membership in group N3.  When the responses are
      generated, the responses are sent with destination address set to
      the multicast group address.  Thus all member hosts of a group
      will receive the responses sent by the other hosts in the subnet
      who are members of the same group.

      In the above example if t1 < t3,  IGMP_host in H1 will generate a
      response to update the membership in group N1 before H3 does and
      H3 will also receive this response in addition to the router. When
      IGMP_host in H3 receives the response sent by H1,  IGMP_host in H3
      cancels the event scheduled at time t3, since a response for that
      group has been sent to the router.  To make this work, the events





Pullen, et. al.              Informational                      [Page 8]

RFC 2490                 IP Multicast with RSVP             January 1999


      to generate response to queries are scheduled randomly, and the
      interval for scheduling the above described event is forced to be
      less than the interval at which router sends the queries.
   3. Accept responses sent by the other hosts in the subnet if any
      application layer is a member of the group to which the packet is
      destined.
   4. Accept terminate group requests from the Application layer. These
      requests are generated by application layer when a application
      decides to leave a group. The IGMP_host updates the group
      information table and subsequently will not send any response
      corresponding to this group (unless another application is a
      member of this group).  When a router does not receive any
      response for a group in certain amount of time on a specific
      interface, membership of that interface is canceled in that group.

   e. Unicast best-effort (UBE) processor node: This node is used to
   generate a best effort traffic in the Internet based on the User
   Datagram Protocol (UDP).  The objective of this node is to model the
   background traffic in a network. This traffic does not use the
   services provided by RSVP. UBE node aims to create the behaviors
   observed in a network which has one type of application using the
   services provided by RSVP to achieve specific levels of QoS and the
   best effort traffic which uses the services provided by only the
   underlying IP.

   The UBE node generates traffic to a randomly generated IP address so
   as to model competing traffic in the network from applications such
   as FTP. The packets generated are sent to the IP layer which routes
   the packet based upon the information in the routing table. The
   attributes of the UBE node are:

   1. Session InterArrival Time (IAT): is the variable used to schedule
      an event to begin a session. The UBE node generates an
      exponentially distributed random variable with mean Session IAT
      and begins to generate data traffic at that time.
   2. Data IAT: When the UBE generates data traffic, the interarrival
      times between data packets is Data IAT. A decrease in the value of
      Data IAT increases the severity of congestion in the network.
   3. Session-min and Session-max: When the UBE node starts generating
      data traffic it remains in that session for a random period which
      is uniformly distributed between Session-min and Session-max.

   f. Multicast Application processor node: The application layer
   consists of one or more application nodes which are process nodes.
   These nodes use the services provided by lower layer protocols IGMP,
   RSVP and IP.  The Application layer models the requests and traffic
   generated by Application layer programs. Attributes of the
   application layer are:



Pullen, et. al.              Informational                      [Page 9]

RFC 2490                 IP Multicast with RSVP             January 1999


   1. Session IAT: is the variable used to schedule an event to begin a
      session.  The Application node generates an exponentially
      distributed random variable with mean Session IAT and begins to
      generate information for a specific group at that time and also
      accept packets belonging to that group.
   2. Data IAT: When Application node generates data traffic, the inter
      arrival time between the packets uses Data IAT variable as the
      argument.  The distribution can be any of the available
      distribution functions in OPNET.
   3. Session-min and Session-max: When an application joins a session
      the duration for which the application stays in that session is
      bounded by Session-min and Session-max.  A uniformly distributed
      random variable between Session-min and Session-max is generated
      for this purpose. At any given time each node will have zero or
      one flow(s) of data.
   4. NGRPS: This variable is used by the application generating
      multicast traffic to bound the value of the group to which an
      application requests  the IGMP to join.  The group is selected at
      random from the range [0,NGRPS-1].

                      [Figure 6: Node Level of Gateway]

3.3.3 Router description

      There are two types of routers in the model, a router serving a
      subnet and a backbone router.  A subnet router has all the
      functions of a backbone router and in addition also has a
      interface to the underlying subnet which can be either a FDDI
      network or a Ethernet subnet. In the following section the subnet
      router will be discussed in detail.

      Figure 6 shows the node level model of a subnet router.

      a. The queueing technique implemented in the router is a
      combination of input and output queueing.  The nodes rx1 to rx10
      are the receivers connected to incoming links.  The router in
      Figure 6 has a physical interface to the FDDI ring or Ethernet,
      which consists of the queue node MAC, transmitter phy_tx, and the
      receiver phy_rx.  The backbone routers will not have a MAC layer.
      The services provided and the functions of the MAC layer are the
      same as the MAC layer in the host discussed above.

      There is one major difference between the MAC node in a subnet
      router and that in a host.  The MAC node in a subnet router
      accepts all arriving multicast packets unlike the MAC in a host
      which accepts only the multicast packets for groups of which the





Pullen, et. al.              Informational                     [Page 10]

RFC 2490                 IP Multicast with RSVP             January 1999