rfc3082.txt

RFC 的详细文档！

   As in small networks, notification is performed primarily by SAs.  If
   an SA receives a DAAdvert or SrvAck with a NotifyAt extension and the
   following conditions are met:

           1. The SA supports notification.

           2. The SA's service type matches the service type in the
              NotifyAt extension.

           3. The SA's scopes match one of the scopes of the NotifyAt
              extension.






Kempf & Goldschmidt           Experimental                      [Page 5]

RFC 3082         Notification and Subscription for SLP        March 2001


   then the SA saves the multicast addresses that correspond to the
   scopes and service types it supports.  The SA MUST perform
   notification immediately after the SA has performed the SrvReg or
   SrvDereg with the DA.  An SA that has detected a DA in its scopes
   MUST NOT multicast any notifications unless it receives a NotifyAt
   extension in a SrvAck with service type and scopes matching the SA's
   service type and scopes.

6. Subscribe Extension

   The Subscribe extension has the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Extension Type = 0x0004    |        Extension Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ex. Len. (ct) | Abs. Type Fl. |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The scope list and service type of the extension are taken from the
   accompanying SrvRqst.  The abstract type flag indicates whether the
   UA is interested in hearing from all SAs advertising concrete
   instances of an abstract type [3], and is only of interest if the
   service type in the SrvRqst is a concrete type.  If the flag is 1,
   the UA is interested in hearing from all SAs advertising concrete
   types having the same abstract type as the type of the SrvRqst.  If
   the flag is 0, the UA is only interested in hearing from SAs
   supporting the particular concrete type in the SrvRqst.  If the
   service type in the accompanying SrvRqst is not a concrete type, the
   flag is ignored.

7. NotifyAt Extension

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Extension Type = 0x0005    |        Extension Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ext. Len (ct) |  Subscription Lifetime        |SGL List Len.  \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |SGL L. Len (ct)|       Scope/Group List                        \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Length of Service Type Name  |        Service Type Name      \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Kempf & Goldschmidt           Experimental                      [Page 6]

RFC 3082         Notification and Subscription for SLP        March 2001


   The service type name is in the same format as in the SrvRqst.  The
   scope/group list is a list of scope names and multicast group
   addresses.  The following ABNF [5] syntax describes the list:

        sglist          = sgitem / sgitem "," sglist
        sgitem          = scope-name ":" ip-addr
        ip-addr         = ipv4-number | ipv6-number
        scope-name      =  ; See RFC 2608 for the format of scope names.
        ipv4-number     =  1*3DIGIT 3("." 1*3DIGIT)
        ipv6-number     = ;See RFC 2373 [9] Section 2.2

   An example of a scope/group list for IPv4 is:

        eng:239.255.255.42,corp:239.255.255.43

   An example of a scope/group listfor IPv6 is:

        eng:FF02:0:0:0:0:0:1:1042,corp:FF03:0:0:0:0:0:1:1042

   The scope/group list gives the multicast addresses to use for
   notifications involving the service type for the given scopes.

   The service type name can be a simple type name, an abstract type
   name, or a concrete type name.  If the name is an abstract type name,
   all SAs advertising the abstract type MUST notify.  If the name is a
   concrete or simple type name, ONLY those SAs advertising the simple
   or concrete type MUST notify, others MUST NOT notify.  A DA that
   receives a subscription for a concrete type with the abstract type
   flag set, MUST include the abstract type name in all the NotifyAt
   messages it sends.  If the DA receives a subscription for a concrete
   type with the abstract type flag not set, the DA MUST NOT include the
   abstract type, but rather MUST include the concrete type name.

   There are three cases in which an agent may receive a NotifyAt
   extension: in a SrvRply returned to a UA, in a multicast DAAdvert,
   and in a SrvAck returned to an SA.  The three subsections below
   describe the response in each of these cases.

7.1 NotifyAt received with SrvRply

   When a UA sends a SrvRqst with a Subscribe extension, the DA responds
   with a SrvRply including a NotifyAt.  The DA MUST NOT unicast a
   NotifyAt to a UA with any other message and MUST NOT send a NotifyAt
   unless a SrvRqst with a Subscribe extension was received.

   The UA responds by setting up a multicast listener to the group
   addresses included in the extension on the SLP notification port
   1847.  The UA MAY also want to note the expiration lifetime of the



Kempf & Goldschmidt           Experimental                      [Page 7]

RFC 3082         Notification and Subscription for SLP        March 2001


   subscription assigned by the DA, and reissue a  subscription before
   the lifetime expires.

7.2 NotifyAt received with Multicast DAAdvert

   The DA multicasts a NotifyAt with a DAAdvert using the multicast
   transmit algorithm when a UA has requested notification and the
   scopes and service type in the subscription were not previously seen.
   This message informs existing SAs having the service type and scopes
   in the announcement that they should multicast notifications when
   they shut down.

   A receiving SA participating in notification responds by noting the
   multicast address if the service type and scopes match.  When the SA
   is about to go down, the SA MUST first unicast a SrvDereg without
   attribute tag list to its DAs (as per standard SLP), then it MUST
   multicast the same SrvDereg message according to the multicast
   transmit algorithm.  The SA MUST cease performing notification when
   the subscription lifetime expires, unless a subsequent NotifyAt is
   received prolonging the subscription.

   A UA that is performing passive DA detection will naturally also
   receive the extension, but the UA SHOULD ignore the extension.

7.3 NotifyAt received with SrvAck

   An SA can receive a NotifyAt with a SrvAck when it first comes up and
   registers itself with a DA.  If the DA has any subscriptions from UAs
   for the service type and scopes represented by the SA, it MUST return
   a NotifyAt with the SrvAck.

   The SA upon receiving the NotifyAt immediately multicasts the same
   SrvReg it sent to the DA, according to the multicast transmit
   algorithm.  The SA MUST only perform the multicast algorithm once,
   even if it registers with more than one DA and receives the NotifyAt
   in reply from more than one.  Prior to its demise and after
   deregistering with a DA, the SA MUST notify with the same SrvDereg,
   as described in Section 7.2.

8. Multicast Address Allocation

   Enterprise networks that allow SLP notification SHOULD deploy the
   Multicast Address Allocation Architecture (MAAA) including
   administratively scoped multicast and Multicast Address Dynamic
   Client Allocation Protocol (MADCAP) [6].

   If it is not possible to obtain a multicast address for use in SLP
   notifications, the SLP multicast address is used.



Kempf & Goldschmidt           Experimental                      [Page 8]

RFC 3082         Notification and Subscription for SLP        March 2001


   If the MAAA infrastructure is deployed, DAs and SAs obtain their
   scope configuration from MADCAP, because the SLP scopes are the same
   as the MADCAP scopes.  Each SLP scope MUST correspond to a multicast
   scope name, in the sense of [6].  In such a case, a DA allocates,
   using MADCAP, a new multicast group address for each new service
   type/scope pair to which a UA subscribes.  The allocation is made by
   MADCAP from the multicast address range for the scope.  In this way,
   only those UAs interested in the service type and scopes in the
   subscription receive the multicast notification.  The DA sets up the
   lease on the multicast address to correspond with the duration of the
   subscription.  If the MADCAP server runs out of addresses, the SLP
   multicast group is used as a last resort.

   For example, if the multicast scope has an address range of 239.1.0.0
   through 239.1.255.255, the notification group address for service
   type X in scope A could be 239.1.0.42 and for service type Y in scope
   B could be 239.1.42.42.

9. Multicast Transmit Algorithm

   The DA and SAs use a multicast transmit algorithm similar to that
   used for discovering services in SLP, described in RFC 2608 [1],
   except the agent performing the notification doesn't wait for
   replies.  The agent performing the notification transmits a
   notification message repeatedly over a period of 15 seconds, backing
   off exponentially on the duration of the time interval between the
   multicasts.  The rationale for this algorithm is to limit the
   duration and scope of the multicast announcement while still
   repeating the announcement enough times to increase the probability
   that one message gets through.

   For an SA, a notification message is either a SrvReg or a SrvDereg
   message, depending on whether the SA is registering a new service or
   deregistering a service.  When a new service is registered, the
   SrvReg message MUST have the fresh bit set in the SLP header.  The
   entire list of attributes for the service SHOULD be included.  The
   SrvDereg message MUST NOT include an attribute tag list.
   Notifications MUST NOT be transmitted at any other time, to minimize
   multicast traffic.

   Since a SrvReg could contain attribute lists of arbitrary length, the
   message could potentially overflow the packet MTU for UDP.  If an
   attribute list causes a packet MTU overflow, the SA MUST set the
   overflow bit in the SLP header.  The attribute list in the
   notification message MUST be formatted so that a UA can use the
   attributes even if an overflow occurs.  If a UA needs more attributes
   than are transmitted in the notification message, it can contact the
   SA (if no DA is present) or the DA for the attributes it needs.



Kempf & Goldschmidt           Experimental                      [Page 9]

RFC 3082         Notification and Subscription for SLP        March 2001


   A DA multicasts a DAAdvert when a subscription comes in containing a
   service type and scopes that do not match any on the DA's list of
   known subscriptions.  The same algorithm MUST be used.  If the
   combination of the DA attributes and the NotifyAt message cause the
   DAAdvert to overflow a UDP packet, DA attributes MUST be truncated to
   allow the NotifyAt to fit and the overflow bit MUST be set in the
   header.  An SA knows that the purpose of the message is to inform it
   of a new subscription rather than for passive advertisement, because
   of the extension, and it can therefore ignore the DA attribute list
   field if the overflow bit is set in the header.  A DA also transmits
   a SrvDereg message when a service advertisement is deregistered due
   to timeout, following the same rules as for an SA.

10.0 DA Disappearance

   Robustness to DA failure is an important goal of the design.  When a