rfc3082.txt

RFC 的详细文档！

   DA disappears due to unforeseen circumstances, subscription
   information from UAs is lost.  UAs continue to get notifications from
   existing SAs.  However, new SAs will not be informed of the
   subscription unless other DAs also have the subscription information.
   Because a UA may not discover a new DA until it tries to perform an
   active request, the UA could potentially miss the appearance of new
   services.  For this reason, UAs that are concerned about receiving
   notification of absolutely every service that appears SHOULD issue
   subscriptions to every newly discovered DA that supports the scopes
   it supports.  Similarly, if a DA disappears through controlled
   shutdown, a UA performing passive discovery can detect the shutdown
   and reissue the subscription to an alternate DA.

   On the SA side, when a DA goes down, existing SAs continue to notify
   until the subscription expires.  Before ceasing to notify, an SA MUST
   determine whether the DA is still active and, if not, verify with
   another DA whether the subscription has been extended.  If no other
   DA is available, the SA MUST ignore the subscription expiration time
   and continue notifying until a new DA is discovered.  When a new DA
   is discovered the SA must send a new SrvReg to the DA, according to
   RFC 2608 [1].  The replying SrvAck contains a NotifyAt extension if
   the UA has renewed its subscription with the DA.  If the SrvAck does
   not contain a NotifyAt message the SA MUST continue to notify until
   the subscription expires.  If a UA is interested in continuing the
   notification, it renews the subscription with the new DA prior to the
   expiration  of the old one, and so the SA is informed to continue
   notifying.








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


   Note that this procedure still does not inform SAs that come up
   between the time a newly booted DA comes up and the time the UA has
   renewed its subscription with the newly booted DA.  If this situation
   is of concern, multiple DAs can be used to assure that all
   subscriptions are covered when a DA goes down.

11.  Network Administration Considerations

   In SLP networks with DAs as described in RFC 2608, the only multicast
   is the SrvRqst for DAAdverts performed during active DA discovery,
   and unsolicited DAAdverts sent periodically by the DA for passive
   discovery.  There is no multicast involved in UA queries or SA
   registrations.  This allows network administrators to set up DAs for
   a particular collection of IP subnets and confine all service
   discovery traffic to unicast between the SA and UA clients and the
   DA.  Administratively scoped multicast can additionally be used to
   limit the extent of active DA discovery and passive DA advertising.
   The amount of multicast involved is not high and DHCP DA and scope
   configuration can be used to limit which DAs a particular UA or SA
   client sees, or to inhibit multicast entirely so that UAs and SAs
   only use configured DAs.

   With notification, however, multicast traffic involving events in SAs
   becomes available.  Because DAs request multicast addresses based on
   scope and service type, the multicast associated with particular
   events should only propagate to those subnets in which UAs and SAs of
   the same scope are interacting.  Routers should be configured with
   administrative multicast scoping to limit multicast.  If DAs are not
   deployed (or the MAAA is not deployed), however, the amount of
   multicast on the SLP multicast address when notifications are being
   used could quickly become very large.  Therefore, it is crucial that
   DAs supporting notification be deployed in large networks where UA
   clients are interested in notification.

12. Security Considerations

   The SrvReg and SrvDereg messages contain authentication blocks for
   all SLP SPIs supported by the DAs with which the SA registers.  Since
   these SPIs are necessarily the same as those that UAs can verify, a
   UA receiving a multicast notification is in a position to verify the
   notification.  It does so by selecting the authentication block or
   blocks that it can verify.  If authentication fails, either due to
   lack of an authentication block, or lack of the proper SPI, the UA
   simply discards the notification.  In a network without DAs, the SPIs
   of the UA and SA must also match.






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


13. IANA Considerations

   The SLP Notification services use the IANA-assigned port number of
   1847.  The SLP extension identifiers assigned by IANA are 0x0004 for
   Subscribe and 0x0005 for NotifyAt.

14. Acknowledgements

   The authors would like to thank Charles Perkins, of Nokia, and Erik
   Guttman and Jonathan Wood, of Sun Microsystems, for their stimulating
   discussion and suggestions during the initial phases of the
   subscription/notification design.  We would also like to thank Erik
   for his intense scrutiny of the specification during the later
   phases.  His comments were instrumental in refining the design.
   Shivaun Albright, of HP, motivated simplification of the protocol to
   focus on initial registration and deregistration only.  Vaishali
   Mithbaokar implemented the simplified protocol.

15. References

   [1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
       Location Protocol", RFC 2608, July 1999.

   [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [3] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
       service: Schemes", RFC 2609, July 1999.

   [4] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July
       1998.

   [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
       Specifications: ABNF", RFC 2234, November 1997.

   [6] Hanna, S., Patel,B. and M. Shah, "Multicast Address Dynamic
       Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

   [7] http://www.isi.edu/in-notes/iana/assignments/multicast-addresses

   [8] Guttman, E., "Service Location Protocol Modifications for IPv6",
       Work in Progress.

   [9] Hinden, R. and S. Deering, "IP Version 6 Addressing
       Architecture", RFC 2375, July 1997.






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


16. Author's Addresses

   James Kempf
   Sun Microsystems
   UMPK15-214
   901 San Antonio Rd.
   Palo Alto, CA 94040
   USA

   Phone:    [phone]
   EMail:    [e-mail]


   Jason Goldschmidt
   Sun Microsystems
   UMPK17-202
   901 San Antonio Rd.
   Palo Alto, CA 94040
   USA

   Phone: [phone]
   EMail: [e-mail]





























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


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kempf & Goldschmidt           Experimental                     [Page 14]