rfc2608.txt

SLP协议在linux下的实现。此版本为1.2.1版。官方网站为www.openslp.org

8.2. Service Reply

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Service Location header (function = SrvRply = 2)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Error Code             |        URL Entry count        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       <URL Entry 1>          ...       <URL Entry N>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The service reply contains zero or more URL entries (see Section
   4.3).  A service reply with zero URL entries MUST be returned in
   response to a unicast Service Request, if no matching URLs are
   present.  A service reply with zero URL entries MUST NOT be sent in
   response to a multicast or broadcast service request (instead, if
   there was no match found or an error processing the request, the
   service reply should not be generated at all).

   If the reply overflows, the UA MAY simply use the first URL Entry in
   the list.  A URL obtained by SLP may not be cached longer than
   Lifetime seconds, unless there is a URL Authenticator block present.





Guttman, et al.             Standards Track                    [Page 21]

RFC 2608         Service Location Protocol, Version 2          June 1999


   In that case, the cache lifetime is indicated by the Timestamp in the
   URL Authenticator (see Section 9.2).

   An authentication block is returned in the URL Entries, including the
   SLP SPI in the SrvRqst.  If no SLP SPI was included in the request,
   no Authentication Blocks are returned in the reply.  URL
   Authentication Blocks are defined in Section 9.2.1.

   If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless
   it fits entirely without truncation.

8.3. Service Registration

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Service Location header (function = SrvReg = 3)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          <URL-Entry>                          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | length of service type string |        <service-type>         \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     length of <scope-list>    |         <scope-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of attr-list string   |          <attr-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |# of AttrAuths |(if present) Attribute Authentication Blocks...\
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The <entry> is a URL Entry (see section 4.3).  The Lifetime defines
   how long a DA can cache the registration.  SAs SHOULD reregister
   before this lifetime expires (but SHOULD NOT more often than once per
   second).  The Lifetime MAY be set to any value between 0 and 0xffff
   (maximum, around 18 hours).  Long-lived registrations remain stale
   longer if the service fails and the SA does not deregister the
   service.

   The <service-type> defines the service type of the URL to be
   registered, regardless of the scheme of the URL. The <scope-list>
   MUST contain the names of all scopes configured for the SA, which the
   DA it is registering with supports.  The default value for the
   <scope-list> is "DEFAULT" (see Section 11).

   The SA MUST register consistently with all DAs.  If a SA is
   configured with scopes X and Y and there are three DAs, whose scopes
   are "X", "Y" and "X,Y" respectively, the SA will register the with
   all three DAs in their respective scopes.  All future updates and
   deregistrations of the service must be sent to the same set of DAs in



Guttman, et al.             Standards Track                    [Page 22]

RFC 2608         Service Location Protocol, Version 2          June 1999


   the same scopes the service was initially registered in.

   The <attr-list>, if present, specifies the attributes and values to
   be associated with the URL by the DA (see Section 5).

   A SA configured with the ability to sign service registrations MUST
   sign each of the URLs and Attribute Lists using each of the keys it
   is configured to use, and the DA it is registering with accepts.
   (The SA MUST acquire DAAdverts for all DAs it will register with to
   obtain the DA's SLP SPI list and attributes, as described in Section
   8.5).  The SA supplies a SLP SPI in each authentication block
   indicating the SLP SPI configuration required to verify the digital
   signature.  The format of the digital signatures used is defined in
   section 9.2.1.

   Subsequent registrations of previously registered services MUST
   contain the same list of SLP SPIs as previous ones or else DAs will
   reject them, replying with an AUTHENTICATION_ABSENT error.

   A registration with the FRESH flag set will replace *entirely* any
   previous registration for the same URL in the same language.  If the
   FRESH flag is not set, the registration is an "incremental"
   registration (see Section 9.3).

8.4. Service Acknowledgment

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Service Location header (function = SrvAck = 5)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Error Code           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A DA returns a SrvAck to an SA after a SrvReg.  It carries only a two
   byte Error Code (see Section 7).















Guttman, et al.             Standards Track                    [Page 23]

RFC 2608         Service Location Protocol, Version 2          June 1999


8.5. Directory Agent Advertisement

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Service Location header (function = DAAdvert = 8)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Error Code           |  DA Stateless Boot Timestamp  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |DA Stateless Boot Time,, contd.|         Length of URL         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                              URL                              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of <scope-list>    |         <scope-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of <attr-list>     |          <attr-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length of <SLP SPI List>   |     <SLP SPI List> String     \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | # Auth Blocks |         Authentication block (if any)         \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Error Code is set to 0 when the DAAdvert is multicast.  If the
   DAAdvert is being returned due to a unicast SrvRqst (ie.  a request
   without the REQUEST MCAST flag set) the DA returns the same errors a
   SrvRply would.

   The <scope-list> of the SrvRqst must either be omitted or include a
   scope which the DA supports.  The DA Stateless Boot Timestamp
   indicates the state of the DA (see section 12.1).

   The DA MAY include a list of its attributes in the DAAdvert.  This
   list SHOULD be kept short, as the DAAdvert must fit into a datagram
   in order to be multicast.

   A potential scaling problem occurs in SLPv2 if SAs choose too low a
   Lifetime.  In this case, an onerous amount of reregistration occurs
   as more services are deployed.  SLPv2 allows DAs to control SAs
   frequency of registration.  A DA MAY reissue a DAAdvert with a new
   set of attributes at any time, to change the reregistration behavior
   of SAs.  These apply only to subsequent registrations; existing
   service registrations with the DA retain their registered lifetimes.

   If the DAAdvert includes the attribute "min-refresh-interval" it MUST
   be set to a single Integer value indicating a number of seconds.  If
   this attribute is present SAs MUST NOT refresh any particular service
   advertisement more frequently than this value.  If SrvReg with the
   FRESH FLAG not set or SrvDereg with a non-empty tag list updating a



Guttman, et al.             Standards Track                    [Page 24]

RFC 2608         Service Location Protocol, Version 2          June 1999


   particular service are received more often than the value for the
   DA's advertised "min-refresh-interval" attribute the DA SHOULD reject
   the message and return a REFRESH_REJECTED error in the SrvAck.

   The URL is "service:directory-agent://"<addr> of the DA, where <addr>
   is the dotted decimal numeric address of the DA. The <scope-list> of
   the DA MUST NOT be NULL.

   The SLP SPI List is the list of SPIs that the DA is capable of
   verifying.  SAs MUST NOT register services with authentication blocks
   for those SLP SPIs which are not on the list.  DAs will reject
   service registrations which they cannot verify, returning an
   AUTHENTICATION_UNKNOWN error.

   The format of DAAdvert signatures is defined in Section 9.2.1.

   The SLP SPI which is used to verify the DAAdvert is included in the
   Authentication Block.  When DAAdverts are multicast, they may have to
   transmit multiple DAAdvert Authentication Blocks.  If the DA is
   configured to be able to generate signatures for more than one SPI,
   the DA MUST include one Authentication Block for each SPI.  If all
   these Authentication Blocks do not fit in a single datagram (to
   multicast or broadcast) the DA MUST send separate DAAdverts so that
   Authentication Blocks for all the SPIs the DA is capable of
   generating are sent.

   If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert
   contains only the authentication block with the SLP SPI in the
   SrvRqst, if the DA is configured to be able to produce digital
   signatures using that SLP SPI. If the SrvRqst is unicast to the DA
   (the REQUEST MCAST flag in the header is not set) and an unsupported
   SLP SPI is included, the DA replies with a DAAdvert with the Error
   Code set to an AUTHENTICATION_UNKNOWN error.

   UAs SHOULD be configured with SLP SPIs that will allow them to verify
   DA Advertisements.  If the UA is configured with SLP SPIs and
   receives a DAAdvert which fails to be verified using one of them, the
   UA MUST discard it.

8.6. Service Agent Advertisement

   User Agents MUST NOT solicit SA Advertisements if they have been
   configured to use a particular DA, if they have been configured with
   a <scope-list> or if DAs have been discovered.  UAs solicit SA
   Advertisements only when they are explicitly configured to use User
   Selectable scopes (see Section 11.2) in order to discover the scopes
   that SAs support.  This allows UAs without scope configuration to
   make use of either DAs or SAs without any functional difference



Guttman, et al.             Standards Track                    [Page 25]

RFC 2608         Service Location Protocol, Version 2          June 1999


   except performance.

   A SA MAY be configured with attributes, and SHOULD support the
   attribute 'service-type' whose value is all the service types of
   services represented by the SA. SAs MUST NOT respond if the SrvRqst
   predicate is not satisfied.  For example, only SAs offering 'nfs'
   services SHOULD respond with a SAAdvert to a SrvRqst for service type
   "service:service-agent" which includes a predicate "(service-
   type=nfs)".

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Service Location header (function = SAAdvert = 11)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Length of URL         |              URL              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of <scope-list>    |         <scope-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of <attr-list>     |          <attr-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | # auth blocks |        authentication block (if any)          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SA responds only to multicast SA discov