draft-day-svrloc-exclusion-03.nr.txt

Pegasus is an open-source implementationof the DMTF CIM and WBEM standards. It is designed to be por

.\"-----------------------------------------------------------------
.\" Registers to store heading levels as variables
.\"-----------------------------------------------------------------
.nr head1 0 1
.nr head2 0 1
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1

.\"-----------------------------------------------------------------
.\" Return to header level 1, 2, etc. 
.\" resets the level registers and indent
.\"-----------------------------------------------------------------
.de RETURN_HDR_1
.nr head2 0 1
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_1 \\$1 
..

.de RETURN_HDR_2
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_2 \\$1
..
 
.de RETURN_HDR_3
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_3 \\$1
..

.de RETURN_HDR_4
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_4 \\$1
..

.de RETURN_HDR_5
.nr head6 0 1
.in 0 
\.HDR_5 \\$1
..

.\"-----------------------------------------------------------------
.\" Create a level 1, 2, etc,.  heading 
.\" resets indent, creates a TOC entry
.\" Parameter is the title of the heading
.\"-----------------------------------------------------------------
.de HDR_1
.sp 1
.in 0 
\\n+[head1]\\  \\$1
.XS
\\n[head1]\\  \\$1
.XE
.in 3
.. 


.de HDR_2
.sp 1
.in 0 
\\n[head1]\\.\\n+[head2]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\ \\$1
.XE
.in 3
.. 

.de HDR_3
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n+[head3]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\ \\$1
.XE
.in 3
.. 

.de HDR_4
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n+[head4]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\ \\$1
.XE
.in 3
.. 

.de HDR_5
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n+[head5]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\ \\$1
.XE
.in 3
.. 

.de HDR_6
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\.\\n+[head6]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\.\\n[head6]\\ \\$1
.in 3
.XE
.. 

.\"-----------------------------------------------------------------
.\" END MACRO DEFINITIONS
.\"-----------------------------------------------------------------

.pl 58
.po 0
.ll 72
.lt 72
.ds LF Day 
.ds RF FORMFEED[Page %]^
.ds CF 
.ds LH INTERNET DRAFT
.ds CH SLP Exclusion Directive
.ds RH Exp. June 2003  
.hy 0
.ad l
.in 0

   
Internet Engineering Task Force                            Michael Day
INTERNET DRAFT                                                     IBM
07 January 2003				         Expires in six months

.ce 1000
Exclusion Extension for Service Location Protocol v2
draft-day-svrloc-exclusion-03.txt
.ce 0
.sp 5

.in 0
Status of This Memo
.in 3
This document is an Internet-Draft and is subject to
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time.  It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This document is an individual contribution to the Internet
Engineering Task Force (IETF). Comments should be submitted to the
[e-mail] mailing list.

Distribution of this memo is unlimited.
	
.bp
.HDR_1 Introduction 

The Service Location Protocol, Version 2 [1] allows the use of
multicast and broadcast discovery requests.  The SLP exclusion
directive is an extension to SLP that optimizes the use of
multicasting and broadcasting to find services on an intranet. This
document hereafter refers to multicast discovery but all its contents
apply to broadcast discovery as well.

.HDR_2 "Present SLPv2 Multicast Behavior"

Multicast discovery requests allow an SLP User Agent to discover
services with no prior configuration. Multicast discovery requests are
not sent reliably and must be retransmitted in order to find all
services of the desired type on the network.

When SLP v2 SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
they contain a <PRList> of previous respondents. Initially the
<PRList> is empty. When these requests are unicast, the <PRList> is
always empty.

Any DA or SA which sees its address in the <PRList> does not respond
to the request (as specified in RFC 2608).

The User Agent then retransmits the discovery request until the
<PRList> causes no further responses to be elicited or the previous
responder list and the request will not fit into a single datagram or
until CONFIG_MC_MAX seconds elapse[1].

The PR list is an effective mechanism for suppressing duplicate
responses in smaller environments. However, because of the way PR
lists are encoded with the SLP v2 header, the PR List has a limit of
as few as 90 IPv4 addressees, and even fewer IPv6 addresses. This
means in most environments a User Agent may suppress duplicate
responses from approximately 90 host addresses at best.

.HDR_2 Optimizations\ Made\ by\ Exclusion\ Directive

The Exclusion Directive extension presented in this document allows a
User Agent (UA) to direct those Directory Agents (DAs) and Service
Agents (SAs) from which it has already received responses not to
respond to retransmissions of a particular query. Hence subsequent
retransmissions only generate responses from agents from which the
requester has not already received a response.

This extension can be used in conjunction with the SLP v2 PR list.
SAs and DAs which do not understand the Exclusion Directive extension
will ignore it. With the use of the Exclusion Directive extension, SLP
v2 User Agents may perform multicast discovery with a high degree of
success and efficiency, even when the number of respondents reaches
into the thousands. .

.HDR_2 Terminology

In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in RFC 2119 [2].

.bp
.RETURN_HDR_1 Exclusion\ Extension\ Format

The fields in an Exclusion extension form an Exclusion Directive that
tells receiving agents not to respond to a specific request from a
specific host for a specific time interval.

Each Exclusion Directive is     fully  contained within one  SLP    v2
extension block. However, a single SLP v2  request message may contain
multiple Exclusion Directives.  For example, a single Service  Request
may  contain three Exclusion  Directives  within three distinct SLP v2
extension blocks.

.KS
.HDR_2 Exclusion\ Extension\ Fields

The Exclusion extension has the following format:
.DS L


   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 ID = 0x000?        |     Next Extension Offset     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Offset, contd.|     size      |        Exclusion XID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Nonce                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Exclusion Interval           |    Number of Entries          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Exclusion Entries                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | # auth blocks                 | authentication block (if any) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

.DE
.KE 
.HDR_3 Size\ Field

The size field specifies the size, in bytes, of each address entry. A
size value of 4 bytes MUST be encoded as an IP v4 address in network
byte order. A size value of 16 bytes MUST be encoded as an IP v6
address in network byte order. Other address sizes are assumed to be
opaque data and will not be interoperable among different
implementations

.HDR_4 Using\ the\ Size\ Field\ to\ Calculate\ Length\ of\ Entries

The size of the Exclusion Entries field MUST be calculated by
multiplying the value of the Size field by the value of the Number of
Entries field. 

.RETURN_HDR_3 Exclusion\ XID

The Exclusion XID identifies the SLP request to which the enclosing
Exclusion Directive applies. An Exclusion Directive always applies to
exactly one specific XID from exactly one host IP address.

It is possible that the value of XID field in the Exclusion Directive
and the XID in the SLP header of the message containing the Exclusion
Directive will be different. This is a subtle but important point: the
SLP v2 header XID and the Exclusion XID are not equivalent. See
section 3.0 for details of how the exclusion XID works.

.HDR_3 Nonce

The Nonce adds a unique value to each Exclusion Directive that makes
it difficult to mount a denial of service attack by replaying
Exclusion Directives. The Nonce is a 128-bit field which MUST contain
a cryptographic-quality random unique value; or alternatively must be
filled with zero bytes. (If the Nonce is filled with zero bytes, it is
ignored.)

The usage of the Nonce is explained further in section 4.3.

.HDR_3 Exclusion\ Interval

The Exclusion Interval indicates the lifetime, in seconds, of the
containing Exclusion Directive. The interval begins when the SA or DA
receives the Exclusion Directive. Exclusion Directives SHOULD have an
interval from one to several seconds. However, the Exclusion Interval
may need to be increased for unusually large networks or media with
high latency characteristics, such as satellite links. 

.HDR_3  Exclusion\ Entries

The Exclusion Entries field is the list of host IP addresses that are
subject to the containing Exclusion Directive. The length of the Exclusion
Entries field is the number of IP addresses in the list multiplied by
the size of each IP address.

The size of each IP address is determined by the value of the size
field. Each Exclusion Directive therefore may only contain IPv4
addresses or IPv6 addresses, but not both.

.HDR_4 Dual-stack\ IP\ Environments

In environments using both IPv4 and IPv6 addresses it may be necessary
to deliver two Exclusion Directives where otherwise one would be
sufficient. E.g., one Directive containing IPv4 addresses and another
Directive containing IPv6 addresses. One way to accomplish this is to
pack two separate Exclusion Directives into a single SLP
request. Another way involves using dummy request messages to deliver
Exclusion Directives. Dummy request messages are covered in section
3.1 below.

.RETURN_HDR_3 Authentication\ Blocks

The Number of Auth Blocks indicates how many authentication blocks
are contained in the containing Exclusion Directive. The format of the
authentication block is covered in section 4 below.

.KS
.RETURN_HDR_2 Exclusion\ Directive\ Functionality

The purpose of the Exclusion Directive is to cause SAs or DAs to
silently discard specific SLP requests that originate from specific IP
addresses. This purpose aids in the use of multicasting to discover
services in large network environments. The Exclusion Directive makes
multicast discovery  more reliable and efficient by: 

.nr PI 5
.nr step 1 1
.RS
.IP \n[step]. 3
Providing a more compact mechanism to silence previous responders.
.IP \n+[step].
Magnifying the effect of the silencing mechanism by specifying a quiet interval.
.RE
.KE

.HDR_3 Exclusion\ Directive\ State\ Table\ (EDST)

When the Exclusion Directive is present in an SLP request, the
receiving agent uses the directive to create and maintain state
information that causes the receiving agent to ignore and discard
matching requests (possibly including the request containing the
Exclusion Directive).

The Exclusion Directive State Table (EDST) is the collection of
information describing all current Exclusion Directives received by
the agent. EDST entries are a record with five fields: Source Address,
Source Port, exclusion XID , exclusion nonce value, and expiration
time. (The nonce value MAY be zero filled.)

The Exclusion Directive only applies to SLP v2 messages that have the
multicast flag set. The SA or DA MUST respond to SLP v2 messages that
do not have the multicast flag set as specified in [1].

If the incoming request message matches a current record in the
receiving agent's EDST, and if the incoming request's Multicast flag
is set in the SLP header, the DA or SA MUST silently discard the
message. 

When the Exclusion Interval of an Exclusion Directive has expired, the
SA or DA MUST delete the corresponding record in its EDST and resume
processing SLP v2 multicast request as if that Exclusion Directive
was never received.

If an incoming request does not contain an Exclusion Directive, the
receiving agent MUST process that request without regard to the local
EDST. (In other words, process the request normally.)


.RETURN_HDR_1  Exclusion\ Directives\ in\ SLP\ v2\ Request\ Messages

An SA or DA may encounter the Exclusion Directive in Service Request,
Attribute Request, and Service Type Request messages. In each case,
the request may also contain a PR list as described in [1].

A UA MUST NOT include an Exclusion Directive in a unicast SLP v2