tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7016

 
 
 

Adobe's Secure Real-Time Media Flow Protocol

Part 3 of 4, p. 45 to 75
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 45 
3.  Operation

3.1.  Overview

              +--------+                             +--------+
              | Peer A |        S E S S I O N        | Peer B |
              |        /=============================\        |
              |       ||            Flows            ||       |
              |       ||---------------------------->||       |
              |       ||---------------------------->||       |
              |       ||<----------------------------||       |
              |       ||<----------------------------||       |
              |       ||<----------------------------||       |
              |        \=============================/        |
              |        |                             |        |
              |        |                             +--------+
              |        |
              |        |                             +--------+
              |        |        S E S S I O N        | Peer C |
              |        /=============================\        |
              |       ||            Flows            ||       |
              |       ||---------------------------->||       |
              |       ||<----------------------------||       |
              |       ||<----------------------------||       |
              |        \=============================/        |
              |        |                             |        |
              +--------+                             +--------+

        Figure 7: Sessions between Pairs of Communicating Endpoints

   Between any pair of communicating endpoints is a single,
   bidirectional, secured, congestion controlled session.
   Unidirectional flows convey messages from one end to the other within
   the session.

   An endpoint initiates a session to a far end when communication is
   desired.  An initiator begins with one or more candidate destination
   socket addresses, and it may learn and try more candidate addresses
   during startup handshaking.  Eventually, a first suitable response is
   received, and that endpoint is selected.  Startup proceeds to the
   selected endpoint.  In the case of session startup glare, one
   endpoint is the prevailing initiator and the other assumes the role
   of responder.  Encryption keys and session identifiers are negotiated
   between the endpoints, and the session is established.

   Each endpoint may begin sending message flows to the other end.  For
   each flow, the far end may accept it and deliver its messages to the
   user, or it may reject the flow and transmit an exception to the

Top      Up      ToC       Page 46 
   sender.  The flow receiver may close and reject a flow at a later
   time, after first accepting it.  The flow receiver acknowledges all
   data sent to it, regardless of whether the flow was accepted.
   Acknowledgements drive a congestion control mechanism.

   An endpoint may have concurrent sessions with other far endpoints.
   The multiple sessions are distinguished by a session identifier
   rather than by socket address.  This allows an endpoint's address to
   change mid-session without having to tear down and re-establish a
   session.  The existing cryptographic state for a session can be used
   to verify a change of address while protecting against session
   hijacking or denial of service.

   A sender may indicate to a receiver that some user messages are of a
   time critical or real-time nature.  A receiver may indicate to
   senders on concurrent sessions that it is receiving time critical
   messages from another endpoint.  The other senders SHOULD modify
   their congestion control parameters to yield capacity to the session
   carrying time critical messages.

   A sender may close a flow.  The flow is completed when the receiver
   has no outstanding gaps before the final fragment of the flow.  The
   sender and receiver reserve a completed flow's identifier for a time
   to allow in-flight messages to drain from the network.

   Eventually, neither end will have any flows open to the other.  The
   session will be idle and quiescent.  Either end may reliably close
   the session to recover its resources.

   In certain circumstances, an endpoint may be ceasing operation and
   not have time to wait for acknowledgement of a reliable session
   close.  In this case, the halting endpoint may send an abrupt session
   close to advise the far end that it is halting immediately.

3.2.  Endpoint Identity

   Each RTMFP endpoint has an identity.  The identity is encoded in a
   certificate.  This specification doesn't mandate any particular
   certificate format, cryptographic algorithms, or cryptographic
   properties for certificates.

   An endpoint is named by an Endpoint Discriminator.  This
   specification doesn't mandate any particular format for Endpoint
   Discriminators.

   An Endpoint Discriminator MAY select more than one identity and MAY
   match more than one distinct certificate.

Top      Up      ToC       Page 47 
   Multiple distinct Endpoint Discriminators MAY match one certificate.

   It is RECOMMENDED that multiple endpoints not have the same identity.
   Entities with the same identity are indistinguishable during session
   startup; this situation could be undesirable in some applications.

   An endpoint MAY have more than one address.

   The Cryptography Profile implements the following functions for
   identities, certificates, and Endpoint Discriminators, whose
   operation MUST be deterministic:

   o  Test whether a given certificate is authentic.  Authenticity can
      comprise verifying an issuer signature chain in a public key
      infrastructure.

   o  Test whether a given Endpoint Discriminator selects a given
      certificate.

   o  Test whether a given Endpoint Discriminator selects the local
      endpoint.

   o  Generate a Canonical Endpoint Discriminator for a given
      certificate.  Canonical Endpoint Discriminators for distinct
      identities SHOULD be distinct.  If two distinct identities have
      the same Canonical Endpoint Discriminator, an initiator might
      abort a new opening session to the second identity
      (Section 3.5.1.1.1); this behavior might not be desirable.

   o  Given a certificate, a message, and a digital signature over the
      message, test whether the signature is valid and generated by the
      owner of the certificate.

   o  Generate a digital signature for a given message corresponding to
      the near identity.

   o  Given the near identity and a far certificate, determine which one
      shall prevail as Initiator and which shall assume the Responder
      role in the case of startup glare.  The far end MUST arrive at the
      same conclusion.  A comparison function can comprise performing a
      lexicographic ordering of the binary certificates, declaring the
      far identity the prevailing endpoint if the far certificate is
      ordered before the near certificate, and otherwise declaring the
      near identity to be the prevailing endpoint.

Top      Up      ToC       Page 48 
   o  Given a first certificate and a second certificate, test whether a
      new incoming session from the second shall override an existing
      session with the first.  It is RECOMMENDED that the test comprise
      testing whether the certificates are bitwise identical.

   All other semantics for certificates and Endpoint Discriminators are
   determined by the Cryptography Profile and the application.

3.3.  Packet Multiplex

   An RTMFP typically has one or more interfaces through which it
   communicates with other RTMFP endpoints.  RTMFP can communicate with
   multiple distinct other RTMFP endpoints through each local interface.
   Session multiplexing over a shared interface can facilitate peer-to-
   peer communications through a NAT, by enabling third-party endpoints
   such as Forwarders (Section 3.5.1.5) and Redirectors
   (Section 3.5.1.4) to observe the translated public address and inform
   peers of the translation.

   An interface is typically a UDP socket (Section 2.2.1) but MAY be any
   suitable datagram transport service where endpoints can be addressed
   by IPv4 or IPv6 socket addresses.

   RTMFP uses a session ID to multiplex and demultiplex communications
   with distinct endpoints (Section 2.2.2), in addition to the endpoint
   socket address.  This allows an RTMFP to detect a far-end address
   change (as might happen, for example, in mobile and wireless
   scenarios) and allows communication sessions to survive address
   changes.  This also allows an RTMFP to act as a Forwarder or
   Redirector for an endpoint with which it has an active session, by
   distinguishing startup packets from those of the active session.

   On receiving a packet, an RTMFP decodes the session ID to look up the
   corresponding session information context and decryption key.
   Session ID 0 is reserved for session startup and MUST NOT be used for
   an active session.  A packet for Session ID 0 uses the Default
   Session Key as defined by the Cryptography Profile.

3.4.  Packet Fragmentation

   When an RTMFP packet (Section 2.2.4) is unavoidably larger than the
   path MTU (such as a startup packet containing an RHello
   (Section 2.3.4) or IIKeying (Section 2.3.7) chunk with a large
   certificate), it can be fragmented into segments that do not exceed
   the path MTU by using the Packet Fragment chunk (Section 2.3.1).

Top      Up      ToC       Page 49 
   The packet fragmentation mechanism SHOULD be used only to segment
   unavoidably large packets.  Accordingly, this mechanism SHOULD be
   employed only during session startup with Session ID 0.  This
   mechanism MUST NOT be used instead of the natural fragmentation
   mechanism of the User Data (Section 2.3.11) and Next User Data
   (Section 2.3.12) chunks for dividing the messages of the user's data
   flows into segments that do not exceed the path MTU.

   A fragmented plain RTMFP packet is reassembled by concatenating the
   packetFragment fields of the fragments for the packet in contiguous
   ascending order, starting from index 0 through and including the
   final fragment.

   When reassembling packets for Session ID 0, a receiver SHOULD
   identify the packets by the socket address from which the packet
   containing the fragment was received, as well as the indicated
   packetID.

   A receiver SHOULD allow up to 60 seconds to completely receive a
   fragmented packet for which progress is being made.  A packet is
   progressing if at least one new fragment for it was received in the
   last second.

   A receiver MUST discard a Packet Fragment chunk having an empty
   packetFragment field.

   The mode of each packet containing Packet Fragments for the same
   fragmented packet MUST match the mode of the fragmented packet.  A
   receiver MUST discard any new Packet Fragment chunk received in a
   packet with a mode different from the mode of the packet containing
   the first received fragment.  A receiver MUST discard any reassembled
   packet with a mode different than the packets containing its
   fragments.

   In order to avoid jamming the network, the sender MUST rate limit
   packet transmission.  In the absence of specific path capacity
   information (for instance, during session startup), a sender SHOULD
   NOT send more than 4380 bytes nor more than four packets per distinct
   endpoint every 200 ms.

   To avoid resource exhaustion, a receiver SHOULD limit the number of
   concurrent packet reassembly buffers and the size of each buffer.
   Limits can depend, for example, on the expected size of reassembled
   packets, on the rate at which fragmented packets are expected to be
   received, on the expected degree of interleaving, and on the expected
   function of the receiver.  Limits can depend on the available
   resources of the receiver.  There can be different limits for packets
   with Session ID 0 and packets for established sessions.  For example,

Top      Up      ToC       Page 50 
   a busy server might need to allow for several hundred concurrent
   packet reassembly buffers to accommodate hundreds of connection
   requests per second with potentially interleaved fragments, but a
   client device with constrained resources could allow just a few
   reassembly buffers.  In the absence of specific information regarding
   the expected size of reassembled packets, a receiver should set the
   limit for each packet reassembly buffer to 65536 bytes.

3.5.  Sessions

   A session is the protocol relationship between a pair of
   communicating endpoints, comprising the shared and endpoint-specific
   information context necessary to carry out the communication.  The
   session context at each end includes at least:

   o  TS_RX: the last timestamp received from the far end;

   o  TS_RX_TIME: the time at which TS_RX was first observed to be
      different than its previous value;

   o  TS_ECHO_TX: the last timestamp echo sent to the far end;

   o  MRTO: the measured retransmission timeout;

   o  ERTO: the effective retransmission timeout;

   o  Cryptographic keys for encrypting and decrypting packets, and for
      verifying the validity of packets, according to the Cryptography
      Profile;

   o  Cryptographic near and far nonces according to the Cryptography
      Profile, where the near nonce is the far end's far nonce, and vice
      versa;

   o  The certificate of the far end;

   o  The receive session identifier, used by the far end when sending
      packets to this end;

   o  The send session identifier to use when sending packets to the far
      end;

   o  DESTADDR: the destination socket address to use when sending
      packets to the far end;

   o  The set of all sending flow contexts (Section 3.6.2);

   o  The set of all receiving flow contexts (Section 3.6.3);

Top      Up      ToC       Page 51 
   o  The transmission budget, which controls the rate at which data is
      sent into the network (for example, a congestion window);

   o  S_OUTSTANDING_BYTES: the total amount of user message data
      outstanding, or in flight, in the network -- that is, the sum of
      the F_OUTSTANDING_BYTES of each sending flow in the session;

   o  RX_DATA_PACKETS: a count of the number of received packets
      containing at least one User Data chunk since the last
      acknowledgement was sent, initially 0;

   o  ACK_NOW: a boolean flag indicating whether an acknowledgement
      should be sent immediately, initially false;

   o  DELACK_ALARM: an alarm to trigger an acknowledgement after a
      delay, initially unset;

   o  The state, at any time being one of the following values: the
      opening states S_IHELLO_SENT and S_KEYING_SENT, the open state
      S_OPEN, the closing states S_NEARCLOSE and S_FARCLOSE_LINGER, and
      the closed states S_CLOSED and S_OPEN_FAILED; and

   o  The role -- either Initiator or Responder -- of this end of the
      session.

Top      Up      ToC       Page 52 
   Note: The following diagram is only a summary of state transitions
   and their causing events, and is not a complete operational
   specification.

          rcv IIKeying Glare
          far prevails +-------------+   ultimate open timeout
        +--------------|S_IHELLO_SENT|-------------+
        |              +-------------+             |
        |                     |rcv RHello          |
        |                     |                    v
        |                     v             +-------------+
        |<-----------(duplicate session?)   |S_OPEN_FAILED|
        |         yes         |no           +-------------+
        |                     |                    ^
        | rcv IIKeying Glare  v                    |
        | far prevails +-------------+             |
        |<-------------|S_KEYING_SENT|-------------+
        |              +-------------+   ultimate open timeout
        |                     |rcv RIKeying
        |                     |
        |       rcv           v
        |   +-+ IIKeying  +--------+ rcv Close Request
        |   |X|---------->| S_OPEN |--------------------+
        |   +-+           +--------+                    |
        |                   |    |ABRUPT CLOSE          |
        |      ORDERLY CLOSE|    |or rcv Close Ack      |
        |                   |    |or rcv IIKeying       |
        |                   |    |   session override   |
        |                   |    +-------+              |
        |                   v            |              v
        |             +-----------+      |     +-----------------+
        |             |S_NEARCLOSE|      |     |S_FARCLOSE_LINGER|
        |             +-----------+      |     +-----------------+
        |      rcv Close Ack|            |              |rcv Close Ack
        |      or 90 seconds|            v              |or 19 seconds
        |                   |       +--------+          |
        |                   +------>|S_CLOSED|<---------+
        +-------------------------->|        |
                                    +--------+

                      Figure 8: Session State Diagram

Top      Up      ToC       Page 53 
3.5.1.  Startup

3.5.1.1.  Normal Handshake

   RTMFP sessions are established with a 4-way handshake in two round
   trips.  The initiator begins by sending an IHello to one or more
   candidate addresses for the desired destination endpoint.  A
   responder statelessly sends an RHello in response.  The first correct
   RHello received at the initiator is selected; all others are ignored.
   The initiator computes its half of the session keying and sends an
   IIKeying.  The responder receives the IIKeying and, if it is
   acceptable, computes its half of the session keying, at which point
   it can also compute the shared session keying and session nonces.
   The responder creates a new S_OPEN session with the initiator and
   sends an RIKeying.  The initiator receives the RIKeying and, if it is
   acceptable, computes the shared session keying and session nonces.
   The initiator's session is now S_OPEN.

        .     Initiator                                Responder     .
                      | IHello                         |
                      |(EPD,Tag)                       |
        S_IHELLO_SENT |(SID=0)                         |
                      |------------------------------->|
                      |                                |
                      |                         RHello |
                      |              (Tag,Cookie,RCert)|
                      |                         (SID=0)|
                      |<-------------------------------|
        S_KEYING_SENT |                                |
                      | IIKeying                       |
                      |(ISID,Cookie,ICert,SKIC,ISig)   |
                      |(SID=0)                         |
                      |------------------------------->|
                      |                                |
                      |                       RIKeying |
                      |                (RSID,SKRC,RSig)|
                      |          (SID=ISID,Key=Default)| S_OPEN
                      |<-------------------------------|
               S_OPEN |                                |
                      |          S E S S I O N         |
                      |<-------------------(SID=ISID)--|
                      |--(SID=RSID)------------------->|

                        Figure 9: Normal Handshake

   In the following sections, the handshake is detailed from the
   perspectives of the initiator and responder.

Top      Up      ToC       Page 54 
3.5.1.1.1.  Initiator

   The initiator determines that a session is needed for an Endpoint
   Discriminator.  The initiator creates state for a new opening session
   and begins with a candidate endpoint address set containing at least
   one address.  The new session is placed in the S_IHELLO_SENT state.

   If the session does not move to the S_OPEN state before an ultimate
   open timeout, the session has failed and moves to the S_OPEN_FAILED
   state.  The RECOMMENDED ultimate open timeout is 95 seconds.

   The initiator chooses a new, unique tag not used by any currently
   opening session.  It is RECOMMENDED that the tag be cryptographically
   pseudorandom and be at least 8 bytes in length, so that it is hard to
   guess.  The initiator constructs an IHello chunk (Section 2.3.2) with
   the Endpoint Discriminator and the tag.

   While the initiator is in the S_IHELLO_SENT state, it sends the
   IHello to each candidate endpoint address in the set, on a backoff
   schedule.  The backoff SHOULD NOT be less than multiplicative, with
   not less than 1.5 seconds added to the interval between each attempt.
   The backoff SHOULD be scheduled separately for each candidate
   address, since new candidates can be added over time.

   If the initiator receives a Redirect chunk (Section 2.3.5) with a tag
   echo matching this session, AND this session is in the S_IHELLO_SENT
   state, then for each redirect destination indicated in the Redirect:
   if the candidate endpoint address set contains fewer than
   REDIRECT_THRESHOLD addresses, add the indicated redirect destination
   to the candidate endpoint address set.  REDIRECT_THRESHOLD SHOULD NOT
   be more than 24.

   If the initiator receives an RHello chunk (Section 2.3.4) with a tag
   echo matching this session, AND this session is in the S_IHELLO_SENT
   state, AND the responder certificate matches the desired Endpoint
   Discriminator, AND the certificate is authentic according to the
   Cryptography Profile, then:

   1.  If the Canonical Endpoint Discriminator for the responder
       certificate matches the Canonical Endpoint Discriminator of
       another existing session in the S_KEYING_SENT or S_OPEN states,
       AND the certificate of the other opening session matches the
       desired Endpoint Discriminator, then this session is a duplicate
       and SHOULD be aborted in favor of the other existing session;
       otherwise,

Top      Up      ToC       Page 55 
   2.  Move to the S_KEYING_SENT state.  Set DESTADDR, the far-end
       address for the session, to the address from which this RHello
       was received.  The initiator chooses a new, unique receive
       session ID, not used by any other session, for the responder to
       use when sending packets to the initiator.  It computes a Session
       Key Initiator Component appropriate to the responder's
       certificate according to the Cryptography Profile.  Using this
       data and the cookie from the RHello, the initiator constructs and
       signs an IIKeying chunk (Section 2.3.7).

   While the initiator is in the S_KEYING_SENT state, it sends the
   IIKeying to DESTADDR on a backoff schedule.  The backoff SHOULD NOT
   be less than multiplicative, with not less than 1.5 seconds added to
   the interval between each attempt.

   If the initiator receives an RIKeying chunk (Section 2.3.8) in a
   packet with this session's receive session identifier, AND this
   session is in the S_KEYING_SENT state, AND the signature in the chunk
   is authentic according to the far end's certificate (from the
   RHello), AND the Session Key Responder Component successfully
   combines with the Session Key Initiator Component and the near and
   far certificates to form the shared session keys and nonces according
   to the Cryptography Profile, then the session has opened
   successfully.  The session moves to the S_OPEN state.  The send
   session identifier is set from the RIKeying.  Packet encryption,
   decryption, and verification now use the newly computed shared
   session keys, and the session nonces are available for application-
   layer cryptographic challenges.

3.5.1.1.2.  Responder

   On receipt of an IHello chunk (Section 2.3.2) with an Endpoint
   Discriminator that selects its identity, an endpoint SHOULD construct
   an RHello chunk (Section 2.3.4) and send it to the address from which
   the IHello was received.  To avoid a potential resource exhaustion
   denial of service, the endpoint SHOULD NOT create any persistent
   state associated with the IHello.  The endpoint MUST generate the
   cookie for the RHello in such a way that it can be recognized as
   authentic and valid when echoed in an IIKeying.  The endpoint SHOULD
   use the address from which the IHello was received as part of the
   cookie generation formula.  Cookies SHOULD be valid only for a
   limited time; that lifetime SHOULD NOT be less than 95 seconds (the
   recommended ultimate session open timeout).

Top      Up      ToC       Page 56 
   On receipt of an FIHello chunk (Section 2.3.3) from a Forwarder
   (Section 3.5.1.5) where the Endpoint Discriminator selects its
   identity, an endpoint SHOULD do one of the following:

   1.  Compute, construct, and send an RHello as though the FIHello was
       an IHello received from the indicated reply address; or

   2.  Construct and send an Implied Redirect (Section 2.3.5) to the
       FIHello's reply address; or

   3.  Ignore this FIHello.

   On receipt of an IIKeying chunk (Section 2.3.7), if the cookie is not
   authentic or if it has expired, ignore this IIKeying; otherwise,

   On receipt of an IIKeying chunk, if the cookie appears authentic but
   does not match the address from which the IIKeying's packet was
   received, perform the special processing at Cookie Change
   (Section 3.5.1.2); otherwise,

   On receipt of an IIKeying with an authentic and valid cookie, if the
   certificate is authentic according to the Cryptography Profile, AND
   the signature in the chunk is authentic according to the far end's
   certificate and the Cryptography Profile, AND the Session Key
   Initiator Component is acceptable, then:

   1.  If the address from which this IIKeying was received corresponds
       to an opening session in the S_IHELLO_SENT or S_KEYING_SENT
       state, perform the special processing at Glare (Section 3.5.1.3);
       otherwise,

   2.  If the address from which this IIKeying was received corresponds
       to a session in the S_OPEN state, then:

       1.  If the receiver was the Responder for the S_OPEN session and
           the session identifier, certificate, and Session Key
           Initiator Component are identical to those of the S_OPEN
           session, this IIKeying is a retransmission, so resend the
           S_OPEN session's RIKeying using the Default Session Key as
           specified below; otherwise,

       2.  If the certificate from this IIKeying does not override the
           certificate of the S_OPEN session, ignore this IIKeying;
           otherwise,

Top      Up      ToC       Page 57 
       3.  The certificate from this IIKeying overrides the certificate
           of the S_OPEN session; this is a new opening session from the
           same identity, and the existing S_OPEN session is stale.
           Move the existing S_OPEN session to S_CLOSED and abort all of
           its flows (signaling exceptions to the user), then continue
           processing this IIKeying.

       Otherwise,

   3.  Compute a Session Key Responder Component and choose a new,
       unique receive session ID not used by any other session for the
       initiator to use when sending packets to the responder.  Using
       this data, construct and, with the Session Key Initiator
       Component, sign an RIKeying chunk (Section 2.3.8).  Using the
       Session Key Initiator and Responder Components and the near and
       far certificates, the responder combines and computes the shared
       session keys and nonces according to the Cryptography Profile.
       The responder creates a new session in the S_OPEN state, with the
       far-endpoint address DESTADDR taken from the source address of
       the packet containing the IIKeying and the send session
       identifier taken from the IIKeying.  The responder sends the
       RIKeying to the initiator using the Default Session Key and the
       requested send session identifier.  Packet encryption,
       decryption, and verification of all future packets for this
       session use the newly computed keys, and the session nonces are
       available for application-layer cryptographic challenges.

3.5.1.2.  Cookie Change

   In some circumstances, the responder may generate an RHello cookie
   for an initiator's address that isn't the address the initiator would
   use when sending packets directly to the responder.  This can happen,
   for example, when the initiator has multiple local addresses and uses
   one address to reach a Forwarder (Section 3.5.1.5) but another to
   reach the responder.

Top      Up      ToC       Page 58 
   Consider the following example:

   Initiator                    Forwarder                     Responder
   | IHello                         |                                 |
   |(Src=Ix)                        |                                 |
   |------------------------------->|                                 |
   |                                | FIHello                         |
   |                                |(RA=Ix)                          |
   |                                |-------------------------------->|
   |                                                                  |
   |                                                           RHello |
   |                                                       (Cookie:Ix)|
   |<-----------------------------------------------------------------|
   |                                                                  |
   | IIKeying                                                         |
   |(Cookie:Ix,Src=Iy)                                                |
   |----------------------------------------------------------------->|
   |                                                                  |
   |                                             RHello Cookie Change |
   |                                             (Cookie:Ix,Cookie:Iy)|
   |<-----------------------------------------------------------------|
   |                                                                  |
   | IIKeying                                                         |
   |(Cookie:Iy)                                                       |
   |----------------------------------------------------------------->|
   |                                                                  |
   |                                                         RIKeying |
   |<-----------------------------------------------------------------|
   |                                                                  |
   |<======================== S E S S I O N =========================>|

                  Figure 10: Handshake with Cookie Change

   The initiator has two network interfaces: a first preferred interface
   with address Ix = 192.0.2.100:50000, and a second with address Iy =
   198.51.100.101:50001.  The responder has one interface with address
   Ry = 198.51.100.200:51000, on the same network as the initiator's
   second interface.  The initiator uses its first interface to reach a
   Forwarder.  The Forwarder observes the initiator's address of Ix and
   sends a Forwarded IHello (Section 2.3.3) to the responder.  The
   responder treats this as if it were an IHello from Ix, calculates a
   corresponding cookie, and sends an RHello to Ix.  The initiator
   receives this RHello from Ry and selects that address as the
   destination for the session.  It then sends an IIKeying, copying the
   cookie from the RHello.  However, since the source of the RHello is
   Ry, on a network to which the initiator is directly connected, the
   initiator uses its second interface Iy to send the IIKeying.  The
   responder, on receiving the IIKeying, will compare the cookie to the

Top      Up      ToC       Page 59 
   expected value based on the source address of the packet, and since
   the IIKeying source doesn't match the IHello source used to generate
   the cookie, the responder will reject the IIKeying.

   If the responder determines that it generated the cookie in the
   IIKeying but the cookie doesn't match the sender's address (for
   example, if the cookie is in two parts, with a first part generated
   independently of the initiator's address and a second part dependent
   on the address), the responder SHOULD generate a new cookie based on
   the address from which the IIKeying was received and send an RHello
   Cookie Change chunk (Section 2.3.6) to the source of the IIKeying,
   using the session ID from the IIKeying and the Default Session Key.

   If the initiator receives an RHello Cookie Change chunk for a session
   in the S_KEYING_SENT state, AND the old cookie matches the one
   originally sent to the responder, then the initiator adopts the new
   cookie, constructs and signs a new IIKeying chunk, and sends the new
   IIKeying to the responder.  The initiator SHOULD NOT change the
   cookie for a session more than once.

3.5.1.3.  Glare

   Glare occurs when two endpoints attempt to initiate sessions to each
   other concurrently.  Glare is detected by receipt of a valid and
   authentic IIKeying from an endpoint address that is a destination for
   an opening session.  Only one session is allowed between a pair of
   endpoints.

   Glare is resolved by comparing the certificate in the received
   IIKeying with the near end's certificate.  The Cryptography Profile
   defines a certificate comparison function to determine the prevailing
   endpoint when there is glare.

   If the near end prevails, discard and ignore the received IIKeying.
   The far end will abort its opening session on receipt of IIKeying
   from the near end.

   Otherwise, the far end prevails:

   1.  If the certificate in the IIKeying overrides the certificate
       associated with the near opening session according to the
       Cryptography Profile, then abort and destroy the near opening
       session.  Then,

   2.  Continue with normal Responder IIKeying processing
       (Section 3.5.1.1.2).

Top      Up      ToC       Page 60 
3.5.1.4.  Redirector

        +-----------+           +------------+          +-----------+
        | Initiator |---------->| Redirector |          | Responder |
        |           |<----------|            |          |           |
        |           |           +------------+          |           |
        |           |<=================================>|           |
        +-----------+                                   +-----------+

                           Figure 11: Redirector

   A Redirector acts like a name server for Endpoint Discriminators.
   An initiator MAY use a Redirector to discover additional candidate
   endpoint addresses for a desired endpoint.

   On receipt of an IHello chunk with an Endpoint Discriminator that
   does not select the Redirector's identity, the Redirector constructs
   and sends back to the initiator a Responder Redirect chunk
   (Section 2.3.5) containing one or more additional candidate addresses
   for the indicated endpoint.

   Initiator                   Redirector                     Responder
   | IHello                         |                                 |
   |------------------------------->|                                 |
   |                                |                                 |
   |                       Redirect |                                 |
   |<-------------------------------|                                 |
   |                                                                  |
   | IHello                                                           |
   |----------------------------------------------------------------->|
   |                                                                  |
   |                                                           RHello |
   |<-----------------------------------------------------------------|
   |                                                                  |
   | IIKeying                                                         |
   |----------------------------------------------------------------->|
   |                                                                  |
   |                                                         RIKeying |
   |<-----------------------------------------------------------------|
   |                                                                  |
   |<======================== S E S S I O N =========================>|

                  Figure 12: Handshake Using a Redirector

Top      Up      ToC       Page 61 
   Deployment Design Note: Redirectors SHOULD NOT initiate new sessions
   to endpoints that might use the Redirector's address as a candidate
   for another endpoint, since the far end might interpret the
   Redirector's IIKeying as glare for the far end's initiation to the
   other endpoint.

3.5.1.5.  Forwarder

         +-----------+     +-----------+     +---+     +-----------+
         | Initiator |---->| Forwarder |<===>| N |<===>| Responder |
         |           |     +-----------+     | A |     |           |
         |           |<=====================>| T |<===>|           |
         +-----------+                       +---+     +-----------+

                           Figure 13: Forwarder

   A responder might be behind a NAT or firewall that doesn't allow
   inbound packets to reach the endpoint until it first sends an
   outbound packet for a particular far-endpoint address.

   A Forwarder's endpoint address MAY be a candidate address for another
   endpoint.  A responder MAY use a Forwarder to receive FIHello chunks
   sent on behalf of an initiator.

   On receipt of an IHello chunk with an Endpoint Discriminator that
   does not select the Forwarder's identity, if the Forwarder has an
   S_OPEN session with an endpoint whose certificate matches the desired
   Endpoint Discriminator, the Forwarder constructs and sends an FIHello
   chunk (Section 2.3.3) to the selected endpoint over the S_OPEN
   session, using the tag and Endpoint Discriminator from the IHello
   chunk and the source address of the packet containing the IHello for
   the corresponding fields of the FIHello.

Top      Up      ToC       Page 62 
   On receipt of an FIHello chunk, a responder might send an RHello or
   Implied Redirect to the original source of the IHello
   (Section 3.5.1.1.2), potentially allowing future packets to flow
   directly between the initiator and responder through the NAT or
   firewall.

   Initiator                    Forwarder           NAT       Responder
   | IHello                         |                |                |
   |------------------------------->|                |                |
   |                                | FIHello        |                |
   |                                |--------------->|--------------->|
   |                                                 |                |
   |                                                 |         RHello |
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   | IIKeying                                        :                |
   |-------------------------------------------------:--------------->|
   |                                                 :                |
   |                                                 :       RIKeying |
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   |<======================== S E S S I O N ========>:<==============>|

      Figure 14: Forwarder Handshake where Responder Sends an RHello

Top      Up      ToC       Page 63 
   Initiator                    Forwarder           NAT       Responder
   | IHello                         |                |                |
   |------------------------------->|                |                |
   |                                | FIHello        |                |
   |                                |--------------->|--------------->|
   |                                                 |                |
   |                                                 |       Redirect |
   |                                                 | (Implied,RD={})|
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   | IHello                                          :                |
   |------------------------------------------------>:--------------->|
   |                                                 :                |
   |                                                 :         RHello |
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   | IIKeying                                        :                |
   |------------------------------------------------>:--------------->|
   |                                                 :                |
   |                                                 :       RIKeying |
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   |<======================== S E S S I O N ========>:<==============>|

          Figure 15: Forwarder Handshake where Responder Sends an
                             Implied Redirect

3.5.1.6.  Redirector and Forwarder with NAT

             +---+       +---+       +---+      +---+      +---+
             | I |       | N |       | I |      | N |      | R |
             | n |------>| A |------>| n |      | A |      | e |
             | i |       | T |       | t |<====>| T |<====>| s |
             | t |<------|   |<------| r |      |   |      | p |
             | i |       |   |       | o |      |   |      | o |
             | a |       |   |       +---+      |   |      | n |
             | t |       |   |                  |   |      | d |
             | o |<=====>|   |<================>|   |<====>| e |
             | r |       |   |                  |   |      | r |
             +---+       +---+                  +---+      +---+

        Figure 16: Introduction Service for Initiator and Responder
                                behind NATs

Top      Up      ToC       Page 64 
   An initiator and responder might each be behind distinct NATs or
   firewalls that don't allow inbound packets to reach the respective
   endpoints until each first sends an outbound packet for a particular
   far-endpoint address.

   An introduction service comprising Redirector and Forwarder functions
   may facilitate direct communication between endpoints each behind
   a NAT.

   The responder is registered with the introduction service via an
   S_OPEN session to it.  The service observes and records the
   responder's public NAT address as the DESTADDR of the S_OPEN session.
   The service MAY record other addresses for the responder, for example
   addresses that the responder self-reports as being directly attached.

   The initiator begins with an address of the introduction service as
   an initial candidate.  The Redirector portion of the service sends to
   the initiator a Responder Redirect containing at least the
   responder's public NAT address as previously recorded.  The Forwarder
   portion of the service sends to the responder a Forwarded IHello
   containing the initiator's public NAT address as observed to be the
   source of the IHello.

   The responder sends an RHello to the initiator's public NAT address
   in response to the FIHello.  This will allow inbound packets to the
   responder through its NAT from the initiator's public NAT address.

   The initiator sends an IHello to the responder's public NAT address
   in response to the Responder Redirect.  This will allow inbound
   packets to the initiator through its NAT from the responder's public
   NAT address.

   With transit paths created in both NATs, normal session startup can
   proceed.

Top      Up      ToC       Page 65 
   Initiator     NAT-I    Redirector+Forwarder     NAT-R      Responder
   |               |                |                |                |
   | IHello        |                |                |                |
   |(Dst=Intro)    |                |                |                |
   |-------------->|                |                |                |
   |               |--------------->|                |                |
   |               |                | FIHello        |                |
   |               |                |(RA=NAT-I-Pub)  |                |
   |               |                |--------------->|--------------->|
   |               |       Redirect |                |                |
   |               | (RD={NAT-R-Pub,|                |                |
   |               |           ...})|                |                |
   |<--------------|<---------------|                |                |
   |               |                                 |         RHello |
   |               |                                 | (Dst=NAT-I-Pub)|
   |               |                                 :<---------------|
   |               | (*)  <--------------------------:                |
   | IHello        |                                 :                |
   |(Dst=NAT-R-Pub)|                                 :                |
   |-------------->:                                 :                |
   |               :-------------------------------->:--------------->|
   |               :                                 :                |
   |               :                                 :         RHello |
   |               :                                 :<---------------|
   |<--------------:<--------------------------------:                |
   |               :                                 :                |
   | IIKeying      :                                 :                |
   |-------------->:                                 :                |
   |               :-------------------------------->:--------------->|
   |               :                                 :                |
   |               :                                 :       RIKeying |
   |               :                                 :<---------------|
   |<--------------:<--------------------------------:                |
   |               :                                 :                |
   |<=============>:<======== S E S S I O N ========>:<==============>|

            Figure 17: Handshake with Redirector and Forwarder

   At the point in Figure 17 marked (*), the responder's RHello from the
   FIHello might arrive at the initiator's NAT before or after the
   initiator's IHello is sent outbound to the responder's public NAT
   address.  If it arrives before, it may be dropped by the NAT.  If it
   arrives after, it will transit the NAT and trigger keying without
   waiting for another round-trip time.  The timing of this race
   depends, among other factors, on the relative distances of the
   initiator and responder from each other and from the introduction
   service.

Top      Up      ToC       Page 66 
3.5.1.7.  Load Distribution and Fault Tolerance

             +---+    IHello/RHello    +-------------+
             | I |<------------------->| Responder 1 |
             | n |                     +-------------+
             | i |  SESSION  +-------------+
             | t |<=========>| Responder 2 |
             | i |           +-------------+
             | a |   IHello...                 +----------------+
             | t |-------------------------> X | Dead Responder |
             | o |                             +----------------+
             | r |  IHello/RHello   +-------------+
             |   |<---------------->| Responder N |
             +---+                  +-------------+

              Figure 18: Parallel Open to Multiple Endpoints

   As specified in Section 3.2, more than one endpoint is allowed to be
   selected by one Endpoint Discriminator.  This will typically be the
   case for a set of servers, any of which could accommodate a
   connecting client.

   As specified in Section 3.5.1.1.1, an initiator is allowed to use
   multiple candidate endpoint addresses when starting a session, and
   the sender of the first acceptable RHello chunk to be received is
   selected to complete the session, with later responses ignored.  An
   initiator can start with the multiple candidate endpoint addresses,
   or it may learn them during startup from one or more Redirectors
   (Section 3.5.1.4).

   Parallel open to multiple endpoints for the same Endpoint
   Discriminator, combined with selection by earliest RHello, can be
   used for load distribution and fault tolerance.  The cost at each
   endpoint that is not selected is limited to receiving and processing
   an IHello, and generating and sending an RHello.

   In one circumstance, multiple servers of similar processing and
   networking capacity may be located in near proximity to each other,
   such as in a data center.  In this circumstance, a less heavily
   loaded server can respond to an IHello more quickly than more heavily
   loaded servers and will tend to be selected by a client.

   In another circumstance, multiple servers may be located in different
   physical locations, such as different data centers.  In this
   circumstance, a server that is located nearer (in terms of network
   distance) to the client can respond earlier than more distant servers
   and will tend to be selected by the client.

Top      Up      ToC       Page 67 
   Multiple servers, in proximity or distant from one another, can form
   a redundant pool of servers.  A client can perform a parallel open to
   the multiple servers.  In normal operation, the multiple servers will
   all respond, and the client will select one of them as described
   above.  If one of the multiple servers fails, other servers in the
   pool can still respond to the client, allowing the client to succeed
   to an S_OPEN session with one of them.

3.5.2.  Congestion Control

   An RTMFP MUST implement congestion control and avoidance algorithms
   that are "TCP compatible", in accordance with Internet best current
   practice [RFC2914].  The algorithms SHOULD NOT be more aggressive in
   sending data than those described in "TCP Congestion Control"
   [RFC5681] and MUST NOT be more aggressive in sending data than the
   "slow start algorithm" described in Section 3.1 of RFC 5681.

   An endpoint maintains a transmission budget in the session
   information context of each S_OPEN session (Section 3.5), controlling
   the rate at which the endpoint sends data into the network.

   For window-based congestion control and avoidance algorithms, the
   transmission budget is the congestion window, which is the amount of
   user data that is allowed to be outstanding, or in flight, in the
   network.  Transmission is allowed when S_OUTSTANDING_BYTES
   (Section 3.5) is less than the congestion window (Section 3.6.2.3).
   See Appendix A for an experimental window-based congestion control
   algorithm for real-time and bulk data.

   An endpoint avoids sending large bursts of data or packets into the
   network (Section 3.5.2.3).

   A sending endpoint increases and decreases its transmission budget in
   response to acknowledgements (Section 3.6.2.4) and loss according to
   the congestion control and avoidance algorithms.  Loss is detected by
   negative acknowledgement (Section 3.6.2.5) and timeout
   (Section 3.6.2.6).

   Timeout is determined by the Effective Retransmission Timeout (ERTO)
   (Section 3.5.2.2).  The ERTO is measured using the Timestamp and
   Timestamp Echo packet header fields (Section 2.2.4).

   A receiving endpoint acknowledges all received data (Section 3.6.3.4)
   to enable the sender to measure receipt of data, or lack thereof.

   A receiving endpoint may be receiving time critical (or real-time)
   data from a first sender while receiving data from other senders.
   The receiving endpoint can signal its other senders (Section 2.2.4)

Top      Up      ToC       Page 68 
   to cause them to decrease the aggressiveness of their congestion
   control and avoidance algorithms, in order to yield network capacity
   to the time critical data (Section 3.5.2.1).

3.5.2.1.  Time Critical Reverse Notification

   A sender can increase its transmission budget at a rate compatible
   with (but not exceeding) the "slow start algorithm" specified in
   RFC 5681 (with which the transmission rate is doubled every round
   trip when beginning or restarting transmission, until loss is
   detected).  However, a sender MUST behave as though the slow start
   threshold SSTHRESH is clamped to 0 (disabling the slow start
   algorithm's exponential increase behavior) on a session where a Time
   Critical Reverse Notification (Section 2.2.4) indication has been
   received from the far end within the last 800 milliseconds, unless
   the sender is itself currently sending time critical data to the
   far end.

   During each round trip, a sender SHOULD NOT increase the transmission
   budget by more than 0.5% or by 384 bytes per round trip (whichever is
   greater) on a session where a Time Critical Reverse Notification
   indication has been received from the far end within the last 800
   milliseconds, unless the sender is itself currently sending time
   critical data to the far end.

3.5.2.2.  Retransmission Timeout

   RTMFP uses the ERTO to detect when a user data fragment has been lost
   in the network.  The ERTO is typically calculated in a manner similar
   to that specified in "Requirements for Internet Hosts - Communication
   Layers" [RFC1122] and is a function of round-trip time measurements
   and persistent timeout behavior.

   The ERTO SHOULD be at least 250 milliseconds and SHOULD allow for the
   receiver to delay sending an acknowledgement for up to 200
   milliseconds (Section 3.6.3.4.4).  The ERTO MUST NOT be less than the
   round-trip time.

   To facilitate round-trip time measurement, an endpoint MUST implement
   the Timestamp Echo facility:

   o  On a session entering the S_OPEN state, initialize TS_RX_TIME to
      negative infinity, and initialize TS_RX and TS_ECHO_TX to have no
      value.

Top      Up      ToC       Page 69 
   o  On receipt of a packet in an S_OPEN session with the
      timestampPresent (Section 2.2.4) flag set, if the timestamp field
      in the packet is different than TS_RX, set TS_RX to the value of
      the timestamp field in the packet, and set TS_RX_TIME to the
      current time.

   o  When sending a packet to the far end in an S_OPEN session:

      1.  Calculate TS_RX_ELAPSED = current time - TS_RX_TIME.  If
          TS_RX_ELAPSED is more than 128 seconds, then set TS_RX and
          TS_ECHO_TX to have no value, and do not include a timestamp
          echo; otherwise,

      2.  Calculate TS_RX_ELAPSED_TICKS to be the number of whole
          4-millisecond periods in TS_RX_ELAPSED; then

      3.  Calculate TS_ECHO = (TS_RX + TS_RX_ELAPSED_TICKS) MODULO
          65536; then

      4.  If TS_ECHO is not equal to TS_ECHO_TX, then set TS_ECHO_TX to
          TS_ECHO, set the timestampEchoPresent flag, and set the
          timestampEcho field to TS_ECHO_TX.

   The remainder of this section describes an OPTIONAL method for
   calculating the ERTO.  Real-time applications and P2P mesh
   applications often require knowing the round-trip time and RTT
   variance.  This section additionally describes a method for measuring
   the round-trip time and RTT variance, and calculating a smoothed
   round-trip time.

   Let the session information context contain additional variables:

   o  TS_TX: the last timestamp sent to the far end, initialized to have
      no value;

   o  TS_ECHO_RX: the last timestamp echo received from the far end,
      initialized to have no value;

   o  SRTT: the smoothed round-trip time, initialized to have no value;

   o  RTTVAR: the round-trip time variance, initialized to 0.

   Initialize MRTO to 250 milliseconds.

   Initialize ERTO to 3 seconds.

Top      Up      ToC       Page 70 
   On sending a packet to the far end of an S_OPEN session, if the
   current send timestamp is not equal to TS_TX, then set TS_TX to the
   current send timestamp, set the timestampPresent flag in the packet
   header, and set the timestamp field to TS_TX.

   On receipt of a packet from the far end of an S_OPEN session, if the
   timestampEchoPresent flag is set in the packet header, AND the
   timestampEcho field is not equal to TS_ECHO_RX, then:

   1.  Set TS_ECHO_RX to timestampEcho;

   2.  Calculate RTT_TICKS = (current send timestamp - timestampEcho)
       MODULO 65536;

   3.  If RTT_TICKS is greater than 32767, the measurement is invalid,
       so discard this measurement; otherwise,

   4.  Calculate RTT = RTT_TICKS * 4 milliseconds;

   5.  If SRTT has a value, then calculate new values of RTTVAR
       and SRTT:

       1.  RTT_DELTA = | SRTT - RTT |;

       2.  RTTVAR = ((3 * RTTVAR) + RTT_DELTA) / 4;

       3.  SRTT = ((7 * SRTT) + RTT) / 8.

   6.  If SRTT has no value, then set SRTT = RTT and RTTVAR = RTT / 2;

   7.  Set MRTO = SRTT + 4 * RTTVAR + 200 milliseconds;

   8.  Set ERTO to MRTO or 250 milliseconds, whichever is greater.

   A retransmission timeout occurs when the most recently transmitted
   user data fragment has remained outstanding in the network for ERTO.
   When this timeout occurs, increase ERTO on an exponential backoff
   with an ultimate backoff cap of 10 seconds:

   1.  Calculate ERTO_BACKOFF = ERTO * 1.4142;

   2.  Calculate ERTO_CAPPED to be ERTO_BACKOFF or 10 seconds, whichever
       is less;

   3.  Set ERTO to ERTO_CAPPED or MRTO, whichever is greater.

Top      Up      ToC       Page 71 
3.5.2.3.  Burst Avoidance

   An application's sending patterns may cause the transmission budget
   to grow to a large value, but at times its sending patterns will
   result in a comparatively small amount of data outstanding in the
   network.  In this circumstance, especially with a window-based
   congestion avoidance algorithm, if the application then has a large
   amount of new data to send (for example, a new bulk data transfer),
   it could send data into the network all at once to fill the window.
   This kind of transmission burst is undesirable, however, because it
   can jam interfaces, links, and buffers.

   Accordingly, in any session, an endpoint SHOULD NOT send more than
   six packets containing user data between receiving any
   acknowledgements or retransmission timeouts.

   The following describes an OPTIONAL method to avoid bursting large
   numbers of packets into the network:

   Let the session information context contain an additional variable
   DATA_PACKET_COUNT, initialized to 0.

   Transmission of a user data fragment on this session is not allowed
   if DATA_PACKET_COUNT is greater than or equal to 6, regardless of any
   other allowance of the congestion control algorithm.

   On transmission of a packet containing at least one User Data chunk
   (Section 2.3.11), set DATA_PACKET_COUNT = DATA_PACKET_COUNT + 1.

   On receipt of an acknowledgement chunk (Sections 2.3.13 and 2.3.14),
   set DATA_PACKET_COUNT to 0.

   On a retransmission timeout, set DATA_PACKET_COUNT to 0.

3.5.3.  Address Mobility

   Sessions are demultiplexed with a 32-bit session ID, rather than by
   endpoint address.  This allows an endpoint's address to change during
   an S_OPEN session.  This can happen, for example, when switching from
   a wireless to a wired network, or when moving from one wireless base
   station to another, or when a NAT restarts.

   If the near end receives a valid packet for an S_OPEN session from a
   source address that doesn't match DESTADDR, the far end might have
   changed addresses.  The near end SHOULD verify that the far end is
   definitively at the new address before changing DESTADDR.  A
   suggested verification method is described in Section 3.5.4.2.

Top      Up      ToC       Page 72 
3.5.4.  Ping

   If an endpoint receives a Ping chunk (Section 2.3.9) in a session in
   the S_OPEN state, it SHOULD construct and send a Ping Reply chunk
   (Section 2.3.10) in response if possible, copying the message
   unaltered.  The Ping Reply SHOULD be sent as quickly as possible
   following receipt of a Ping.  The semantics of a Ping's message is
   reserved for the sender; a receiver SHOULD NOT interpret the Ping's
   message.

   Endpoints can use the mechanism of the Ping chunk and the expected
   Ping Reply for any purpose.  This specification doesn't mandate any
   specific constraints on the format or semantics of a Ping message.  A
   Ping Reply MUST be sent only as a response to a Ping.

   Receipt of a Ping Reply implies live bidirectional connectivity.
   This specification doesn't mandate any other semantics for a
   Ping Reply.

3.5.4.1.  Keepalive

   An endpoint can use a Ping to test for live bidirectional
   connectivity, to test that the far end of a session is still in the
   S_OPEN state, to keep NAT translations alive, and to keep firewall
   holes open.

   An endpoint can use a Ping to hasten detection of a near-end address
   change by the far end.

   An endpoint may declare a session to be defunct and dead after a
   persistent failure by the far end to return Ping Replies in response
   to Pings.

   If used for these purposes, a Keepalive Ping SHOULD have an empty
   message.

   A Keepalive Ping SHOULD NOT be sent more often than once per ERTO.
   If a corresponding Ping Reply is not received within ERTO of sending
   the Ping, ERTO SHOULD be increased according to Section 3.5.2
   ("Congestion Control").

Top      Up      ToC       Page 73 
3.5.4.2.  Address Mobility

   This section describes an OPTIONAL but suggested method for
   processing and verifying a far-end address change.

   Let the session context contain additional variables MOB_TX_TS,
   MOB_RX_TS, and MOB_SECRET.  MOB_TX_TS and MOB_RX_TS have initial
   values of negative infinity.  MOB_SECRET should be a
   cryptographically pseudorandom value not less than 128 bits in length
   and known only to this end.

   On receipt of a packet for an S_OPEN session, after processing all
   chunks in the packet: if the session is still in the S_OPEN state,
   AND the source address of the packet does not match DESTADDR, AND
   MOB_TX_TS is at least one second in the past, then:

   1.  Set MOB_TX_TS to the current time;

   2.  Construct a Ping message comprising the following: a marking to
       indicate (to this end when returned in a Ping Reply) that it is a
       mobility check (for example, the first byte being ASCII 'M' for
       "Mobility"), a timestamp set to MOB_TX_TS, and a cryptographic
       hash over the following: the preceding items, the address from
       which the packet was received, and MOB_SECRET; and

   3.  Send this Ping to the address from which the packet was received,
       instead of DESTADDR.

   On receipt of a Ping Reply in an S_OPEN session, if the Ping Reply's
   message satisfies all of these conditions:

   o  it has this end's expected marking to indicate that it is a
      mobility check, and

   o  the timestamp in the message is not more than 120 seconds in the
      past, and

   o  the timestamp in the message is greater than MOB_RX_TS, and

   o  the cryptographic hash matches the expected value according to the
      contents of the message plus the source address of the packet
      containing this Ping Reply and MOB_SECRET,

Top      Up      ToC       Page 74 
   then:

   1.  Set MOB_RX_TS to the timestamp in the message; and

   2.  Set DESTADDR to the source address of the packet containing this
       Ping Reply.

3.5.4.3.  Path MTU Discovery

   "Packetization Layer Path MTU Discovery" [RFC4821] describes a method
   for measuring the path MTU between communicating endpoints.

   An RTMFP SHOULD perform path MTU discovery.

   The method described in RFC 4821 can be adapted for use in RTMFP by
   sending a probe packet comprising one of the Padding chunk types
   (type 0x00 or 0xff) and a Ping.  The Ping chunk SHOULD come after the
   Padding chunk, to guard against a false positive response in case the
   probe packet is truncated.

3.5.5.  Close

   An endpoint may close a session at any time.  Typically, an endpoint
   will close a session when there have been no open flows in either
   direction for a time.  In another circumstance, an endpoint may be
   ceasing operation and will close all of its sessions even if they
   have open flows.

   To close an S_OPEN session in a reliable and orderly fashion, an
   endpoint moves the session to the S_NEARCLOSE state.

   On a session transitioning from S_OPEN to S_NEARCLOSE and every
   5 seconds thereafter while still in the S_NEARCLOSE state, send a
   Session Close Request chunk (Section 2.3.17).

   A session that has been in the S_NEARCLOSE state for at least
   90 seconds (allowing time to retransmit the Session Close Request
   multiple times) SHOULD move to the S_CLOSED state.

   On a session transitioning from S_OPEN to the S_NEARCLOSE,
   S_FARCLOSE_LINGER or S_CLOSED state, immediately abort and terminate
   all open or closing flows.  Flows only exist in S_OPEN sessions.

   To close an S_OPEN session abruptly, send a Session Close
   Acknowledgement chunk (Section 2.3.18), then move to the S_CLOSED
   state.

Top      Up      ToC       Page 75 
   On receipt of a Session Close Request chunk for a session in the
   S_OPEN, S_NEARCLOSE, or S_FARCLOSE_LINGER states, send a Session
   Close Acknowledgement chunk; then, if the session is in the S_OPEN
   state, move to the S_FARCLOSE_LINGER state.

   A session that has been in the S_FARCLOSE_LINGER state for at least
   19 seconds (allowing time to answer 3 retransmissions of a Session
   Close Request) SHOULD move to the S_CLOSED state.

   On receipt of a Session Close Acknowledgement chunk for a session in
   the S_OPEN, S_NEARCLOSE, or S_FARCLOSE_LINGER states, move to the
   S_CLOSED state.



(page 75 continued on part 4)

Next RFC Part