NSIS X. Fu
Internet-Draft I. Juchem
Expires: September 7, 2006 C. Dickmann
Univ. Goettingen
H. Tschofenig
Siemens
March 6, 2006
Design Options of NSIS Diagnostics NSLP
draft-fu-nsis-diagnostics-nslp-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Next Steps in Signaling protocol suite aims to provide a way to
communicate with network intermediaries. As such, it is desirable to
offer generic diagnostics function for NSIS users and system
administrators to make the functionality provided by the network more
transparent (e.g., to identify particular NSLPs, to determine to
Fu, et al. Expires September 7, 2006 [Page 1]
Internet-Draft Diagnostics NSLP Design Options March 2006
which degree the network supports NSIS, GIST state or specific NSLP
session information along a given path).
Instead of suggesting one specific solution we highlight the
different design options of some simple, stateless diagnostics
functions from a querying node to a responding node. These
preliminary thoughts should help the working group to have a more
structure discussion in this problem space.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Information to be Diagnosed . . . . . . . . . . . . . . . . . 3
3. Information gathering and data transport options . . . . . . . 5
3.1. Basic prerequisites . . . . . . . . . . . . . . . . . . . 5
3.1.1. Basic message objects . . . . . . . . . . . . . . . . 7
3.2. NTLP state information . . . . . . . . . . . . . . . . . . 9
3.2.1. General GIST state information . . . . . . . . . . . . 10
3.2.2. SID-bound state information . . . . . . . . . . . . . 10
3.3. NSLP state information . . . . . . . . . . . . . . . . . . 11
3.3.1. NSLP state information object . . . . . . . . . . . . 11
3.4. Query available NSLPs . . . . . . . . . . . . . . . . . . 12
3.4.1. Available NSLPs object . . . . . . . . . . . . . . . . 12
3.5. Additional information . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. Summary and Open Issues . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Fu, et al. Expires September 7, 2006 [Page 2]
Internet-Draft Diagnostics NSLP Design Options March 2006
1. Introduction
The lack of a unified mechanism for diagnostics capabilities in the
NSIS protocol suite represents a substantial problem, for both the
end user and the system administrator. As the number of vendors and
operators deploying (and possibly extending) NSIS is expected to
increase, the problem of diagnosing the multitude of devices from
different signaling functions, both for general signaling transport
and for particular signaling applications, escalates. Although some
NSLP specifications set out the details of how a device can enquire
some sort of diagnostics data, the extent to which this diagnostics
data is used and converted to meaningful information by the specific
NSLPs varies considerably from one NSLP to another. For instance, in
the current version of QoS-NSLP specification [1], Query messages are
used for detecting path characteristics information from any QNE
towards a QNI. In the case of NATFW NSLP, current specification [2]
defines a Query and Diagnostics Request message used by authorized
NATFW NEs for querying and diagnosing installed NATFW states and it
is still in discussion whether to exclude this feature from the base
specification of the NATFW NSLP. On the other hand, GIST [3] does
not provide an explicit diagnostics function to allow authorized
entities to diagnose the GIST level information; it simply discovers
the next GIST peer and delivers NSLP messages as its payload.
It is expected that the additional administrative or development
effort is required without diagnostic capabilities. RSVP's
diagnostics functions (see [4]) allow any RSVP node to query a RSVP
session's Path state and Resv state (if available). However they
exhibit a lack of the the capability of performing authorized access,
which may be desired to prevent the introduction of security
vulnerabilities (see [5]).
This document describes some key design considerations towards a set
of simple, generic and secure diagnostics functions. The following
aspects seem to be major design decisions:
o Which information is going to be subject for diagnosis?
o At which granularity of the information can be diagnosed?
o Which transport mechanism should be used for delivering
diagnostics messages, and whether to introduce/avoid GIST level
and/or NSLP state
o How to properly authorize a diagnostics operation and protect the
diagnostics messages?
Subsequent sections will discuss these aspects in more details.
2. Information to be Diagnosed
Fu, et al. Expires September 7, 2006 [Page 3]
Internet-Draft Diagnostics NSLP Design Options March 2006
The main purpose of diagnostics NSLP is to diagnose NSIS state
information. One question is which state could and should be
diagnosed, and how much granularity of the state should be possible
to be diagnosed. Corresponding to the 2-layer architecture of NSIS,
there are two types of NSIS states: GIST and NSLP state information.
In case of GIST (or NTLP) state, we also distinguish between state
information we want to collect for states corresponding to one single
Session ID (SID), further labeled "SID-bound state information", and
state information to be collected which is not directly corresponding
to a SID (further called "General GIST state information". We will
list a few state information elements below:
General GIST state information:
GIST state includes:
MA information: The MA information might include a list of the
message associations a GIST node has currently in use. This
involves the properties of the MA, e.g. the used protocol
stack, the address of the corresponding peer and the list of
MRS using the MA. In addition a general information about the
supported protocol stacks (in respect of the GIST stack
proposal) should be included in the diagnostics data.
GIST MRS information: An exhaustive list of the MRS table might
cause the size of a diagnostics messages to increase
dramatically, for example, when the core node supporting tens
of thousands of sessions. It may also be not very helpful and
also not secure without being scoped to a limited network
domain. However, the total numbers of MRSs over an individual
MAs in a GIST node may be of interest to the entity performing
the diagnostics function.
SID-bound state information:
For state information which is directly corresponding to one
single GIST Session ID/NSLPid tupel, more detailed information can
be collected. This includes, but does not limit to, the following
information:
MA information: In contrast to the general GIST state case, the MA
information for the SID-bound state information is limited to
the message associations related to the specific SessionID/
NSLPID tupel.
MRS information: The MRS data might include the MRI and
information about the upstream and downstream peers, as well as
configuration values, such as refresh intervals.
Fu, et al. Expires September 7, 2006 [Page 4]
Internet-Draft Diagnostics NSLP Design Options March 2006
NSLP state:
It is likely possible to collect some information about the NSLP
state corresponding to a particular session ID, if the
authorization issue is addressed. However, it should not allow a
diagnostics message from any querying node to query state
belonging to other sessions or other NSLPs not being the present
node (requestor). For NAT/FW NSLP, it may be interesting for a
requestor to be able to diagnose the existence of NAT and FW
devices (their IP addresses) and if possible, number or detailed
information of NAT bindings or firewall entries, without a per-
session basis. However, this is subject to authorization
decisions in the protocol operation. Also, the QOS NSLP can be
diagnosed for various information.
In addition, collecting general information such as GIST supporting
information (e.g., GIST node IP addresses) or in the case of QoS
NSLP, QOSM ID supporting information in the QoS NSLP supporting nodes
may be possible.
Furthermore, if necessary, one can also calculate the processing
delay information in GIST nodes, by putting timestamps to the
diagnostics messages when they traverse a GIST node. This simple
extension, similar to traceroute, can be added to diagnostics
messages as discussed in [6].
The final information we propose to be gathered from NSIS nodes is
their support for different NSLPs. For a network administrator it
will be helpful to collect which NSLPs are running on a certain node
within the domain. This will help finding out whether an NSLP he is
diagnosing is still/has been running on said peer. Also, it will be
possible to detect still active NSLPs on nodes within the domain
which should no longer be running for security reasons.
3. Information gathering and data transport options
This section will describe conditions and basic usage along with a
proposed message format for GIST diagnostics client messages. It
will also highlight practical usage for different scenarios.
3.1. Basic prerequisites
It is desirable that a diagnostics function does not install any new
state. However sometimes this is inevitable, for example state in
GIST level, especially MRS state even no new MAs will be introduced.
It is possible that the diagnostics messages will be transported in a
stateless mode and the response messages are directly addressed to
Fu, et al. Expires September 7, 2006 [Page 5]
Internet-Draft Diagnostics NSLP Design Options March 2006
the requestor, if it is not necessary to maintain reverse routing
information and modify/add results in the reverse direction. On the
other hand, if a new MRS needs to be created in querying direction,
then it should be removed in the response direction. Therefore, to
avoid state creation on NTLP level, diagnostics messages should be
kept as small as possible.
Diagnostics messages should be limited to fit into a D-mode (e.g.,
UDP) message in size, thus no larger than 64k and likely limited by
the link MTU.
For simplicity and easy implementation we will continue NSIS' message
object approach. This means that messages created by the diagnostic
tool will consist of several objects which themselves could be
compiled by adding various other message objects. By this, we also
enable easy extensibility for further information gathering of yet
unknown NSLPs.
We will limit the diagnostic functions towards sysadmins diagnosing
withing thei own domain only.
Messages by the diagnostics tool consist of one common header
followed by a Query object and a list of Hop objects:
DIAGNOSTIC-message =
Common header, Query object, [Hop object]*
The Query object specifies the requested information every GIST node
should add. A Hop object is added by every GIST node on the path and
contains the requested information. The Hop object itself consists
of a Hop-Header and a list of data objects:
Hop-object =
Hop header
[IPv4 address object]*
[IPv6 address object]*
[General GIST information object]
[SID-bound Response object]
[NSLP state information object]
[Available NSLPs object]
[Additional information object]
The procedure for the diagnostic tools will be as follows:
1. At querying node, compose and send query message with designated
destination - the final GIST node along the path
2. GIST at querying node forwards message to next GIST node towards
the destination
Fu, et al. Expires September 7, 2006 [Page 6]
Internet-Draft Diagnostics NSLP Design Options March 2006
3. Intermediate Diagnostic-NSLP-aware GIST nodes add queried
information if message is on the downstream direction and forward
to next peer
4. The destination GIST node adds queried information and forwards
the message in the downstream direction
The message flow is depicted in Figure 1.
+----------+ +----------+ +----------+
| | | | | |
|Diagnostic| |Diagnostic| |Diagnostic|
| NSLP | | NSLP | | NSLP |
| | | | | |
+----------+ +----------+ +----------+
1. || /\ 3. /\ || 4. /\ ||
\/ || || \/ || \/
+--------+2. +--------+ +--------+ +--------+
| |>>>>>>| |>>>>>>| |> .. >| |
| GIST | | GIST | | GIST | | GIST |
| node | | node | | node | | node |
| |<<<<<<| |<<<<<<| |< .. <| |
+--------+ +--------+ +--------+ +--------+
>> Upstream query message
<< Downstream response message
Figure 1: Diagnostic NSLP message flow
3.1.1. Basic message objects
3.1.1.1. Common Header
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version : Identifier for diagnostic NSLP
Length : Overall message length
3.1.1.2. Standard Object Format
Each object begins with a fixed header giving the object Type and
object Length. This is followed by the object Value, which is a
whole number of 32-bit words long.
Fu, et al. Expires September 7, 2006 [Page 7]
Internet-Draft Diagnostics NSLP Design Options March 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|r|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 00 : Query object
Type 01 : Hop object
Type 02 : IPv4 address object
Type 03 : IPv6 address object
Type 04 : General GIST information object
Type 05 : SID-bound Response object
Type 06 : NSLP state information object
Type 07 : Available NSLPs object
Type 08 : Additional information object object
3.1.1.3. Hop object
The hop object is just a container for the information objects
requested in the Query object.
3.1.1.4. IPv4 address object
Every Hop Object may contain any number of IPv4 address objects.
Length: 4 bytes
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1.5. IPv6 address object
Every Hop Object may contain any number of IPv6 address objects.
Length: 16 bytes
Fu, et al. Expires September 7, 2006 [Page 8]
Internet-Draft Diagnostics NSLP Design Options March 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2. NTLP state information
As described earlier, we distinguish between general GIST state
information and SID-bound state information. When collecting general
GIST state information, one has to be careful to limit the amount of
gathered information to comply to the basic prerequisites, especially
in terms of expected message sizes. For example, when querying for
larger sized information the possible maximum amount of nodes the
query collects data from and replies it to the querying node, has to
be taken into account to not exceed the maximum allowed message size
and thereby risk the loss of data. Therefore, mechanisms to prevent
overlimits of message size caused by the computation of (informative
data size + header sizes) * amount of queried nodes, need to be
present. For example, intermediate peers that identify further
information to exceed the maximum size could intercept the query
process by sending already collected information back to the querying
node and trigger a re-querying. The querying node can now start
querying information from the intercepting node towards the
destination.
Hence we propose an extension to the message flow as shown in Figure
1 by introducing the possibility for every Diagnostic NSLP to act as
a query intercepter:
Fu, et al. Expires September 7, 2006 [Page 9]
Internet-Draft Diagnostics NSLP Design Options March 2006
+----------+ +----------+ +-----------+ +----------+
| | | | |Diagnostic | | |
|Diagnostic| |Diagnostic| | NSLP | |Diagnostic|
| NSLP | | NSLP | | query | | NSLP |
| | | | |intercepter| | |
+----------+ +----------+ +-----------+ +----------+
1. || /\ 3. /\ || 4. /\ || 5. 7. /\ ||
6. \/ || || \/ || \/ || \/
+--------+2. +--------+ +--------+ +--------+
| |>>>>>>| |>>>>>>| |> .. >| |
| GIST | | GIST | | GIST | | GIST |
| node | | node | | node | | node |
| |<<<<<<| |<<<<<<| |< .. <| |
+--------+ +--------+ +--------+ +--------+
>> Upstream query message
<< Downstream response message
Figure 2: Extended message flow with intercepting node
Here we introduce 3 new actions:
1. At querying node, compose and send query message with designated
destination - the final GIST node along the path
2. GIST at querying node forwards message to next GIST node towards
the destination
3. Intermediate Diagnostic-NSLP-aware GIST nodes add queried
information if message is on the downstream direction and forward
to next peer
4. One peer discovers that adding the requested information would
exceed the maximum message size and intercepts the querying
process.
5. The intercepting node sends the already collected informational
data downstream towards the querying node.
6. The querying node extracts the stores the data already collected
along the path up to the intercepting node. It then sends a new
query message directed at the destination node from the
intercepting node on to collect data further along the path.
7. The destination GIST node adds queried information and forwards
the message in the downstream direction
3.2.1. General GIST state information
This will be discussed in a later version
3.2.2. SID-bound state information
This will be discussed in a later version
Fu, et al. Expires September 7, 2006 [Page 10]
Internet-Draft Diagnostics NSLP Design Options March 2006
3.3. NSLP state information
Which information to collect about states linked to a specific SID
depends on the NSLP being queried. However, some basic information
common to all NSLPs could still be gathered, for example the total
amount of states connected to a specific SID. Querying of supported
NSLP-IDs on each GIST node should be limited to Administrators only.
3.3.1. NSLP state information object
NSLP state information object.
Length: Variable
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSLP ID | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|InformationType| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
|InformationType| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NSLP ID: Identifier for queried NSLP
Length : Overall message length
InformationType : Identifier for information that is to be queried
on GIST nodes up to destination
Value : Value of queried information
Information Type could be any data queried at a GIST node which could
be used for diagnosis. Example: Total amount of states maintained by
a QoS NSLP, Value would then contain that amount. When acting as a
query message, only the InformationType fields will be present and
contain the identifier. Intermediate GIST nodes and the destination
GIST node will then enter the values accordingly. This would also
allow for querying multiple types of information.
GIST nodes not able to provide the requested information enter a
value of 0 if they couldn't provide the information due to non
availability and -1 if an error occured into the specific value
field.
Fu, et al. Expires September 7, 2006 [Page 11]
Internet-Draft Diagnostics NSLP Design Options March 2006
3.4. Query available NSLPs
This scenario can be expected to be most widely used. Also, it
should be the most easiest one to deploy and implement aswell as
gather the requested information. The diagnostics NSLP simply
queries for other NSLP IDs on the GIST nodes, collects them and adds
their values to the RESPONSE object together with the total amount of
IDs and finally its IP address.
3.4.1. Available NSLPs object
Available NSLPs object lists the NSLP IDs supported at the given GIST
node.
Length: Variable (depends on the number of NSLPs supported on the
GIST node)
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved | ID of 1st NSLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ID of 2nd NSLP | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Id of nth NSLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length : Overall message length
ID of Xth NSLP : NSIS ID of NSLP existing and supported by GIST
node
3.5. Additional information
Additional information can be gathered by computing the minimum,
maximum and average delay of a roundtrip with values collected by
running an instance of the PING Deamon. Other possible data to be
queried for can include the software version of GIST, the OS running
GIST, amount of known peers and other useful information.
4. Security Considerations
Authorization and protection of the diagnostics messages seem to be
two outstanding issues, among the various issues identified in [7].
Fu, et al. Expires September 7, 2006 [Page 12]
Internet-Draft Diagnostics NSLP Design Options March 2006
On one hand, one may desire that only the state installer can query
the session-specific state. For general information diagnostics,
measures may be desired for allowing administrators only be able to
make the operations across their own domains, or neighboring trusted
domains.
On the other hand, the diagnostics messages carry senstive
information that needs to be integrity protected. Some measures may
be utilized such as reusing the secure MAs (if available) between the
neigboring GIST nodes, or add NSLP level security mechanisms such as
CMS.
A future version of this document will add more security relevant
considerations.
5. Summary and Open Issues
We have discussed in this document how diagnostics functions for NSIS
implementations as a common NSLP could be designed. Our intention is
to keep it as simple and secure as possible.
Further possible additions to the diagnostics function could be
diagnostics support for tunnelling and mobility devices.
A new NSLP ID needs to be defined if a common NSLP for diagnostics
functions is devised.
6. IANA Considerations
A future version of this document will provide details about an IANA
consideration.
7. Acknowledgments
The authors would like to thank Sebastian Willert, Henning Peters,
Luis Cordeiro and Bernd Schloer for the discussion and implementation
of the early ideas. Moreover, Robert Braden, Scott Bradner, Robert
Hancock, John Loughney, Jukka Manner, Andrew McDonald, David Oran and
Martin Stiemerling provided valuable comments.
8. References
Fu, et al. Expires September 7, 2006 [Page 13]
Internet-Draft Diagnostics NSLP Design Options March 2006
8.1. Normative References
[1] Manner, J., "NSLP for Quality-of-Service signalling",
draft-ietf-nsis-qos-nslp-09 (work in progress), February 2006.
[2] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress),
February 2006.
[3] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-09 (work in
progress), February 2006.
8.2. Informative References
[4] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP
Diagnostic Messages", RFC 2745, January 2000.
[5] Tschofenig, H. and R. Graveman, "RSVP Security Properties",
RFC 4230, December 2005.
[6] Juchem, I., "A stateless Ping tool for simple tests of GIMPS
implementations", draft-juchem-nsis-ping-tool-02 (work in
progress), July 2005.
[7] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
Steps in Signaling (NSIS)", RFC 4081, June 2005.
Fu, et al. Expires September 7, 2006 [Page 14]
Internet-Draft Diagnostics NSLP Design Options March 2006
Authors' Addresses
Xiaoming Fu
University of Goettingen
Institute for Informatics
Lotzestr. 16-18
Goettingen 37083
Germany
Email: fu@cs.uni-goettingen.de
Ingo Juchem
University of Goettingen
Institute for Informatics
Lotzestr. 16-18
Goettingen 37083
Germany
Email: ijuchem@cs.uni-goettingen.de
Christian Dickmann
University of Goettingen
Institute for Informatics
Lotzestr. 16-18
Goettingen 37083
Germany
Email: mail@christian-dickmann.de
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Fu, et al. Expires September 7, 2006 [Page 15]
Internet-Draft Diagnostics NSLP Design Options March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fu, et al. Expires September 7, 2006 [Page 16]