Network Working Group J. Manner
Internet-Draft L. Liuhto
Intended status: Standards Track N. Varis
Expires: August 28, 2008 T. Huovila
University of Helsinki
February 25, 2008
Peering Data for NSIS Signaling Layer Protocols
draft-manner-nsis-peering-data-01.txt
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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
When an NSLP protocol initiates a signaling session and requests
either reliable or secure transport (or both), NSLP data can not be
carried within the GIST Query. Thus the NSLP at the responding node
can not have NSLP specific information for peering decisions. Next
generation NSLP protocols may need more information to be able to
make right peering decisions. This draft presents a new Peering
Manner, et al. Expires August 28, 2008 [Page 1]
Internet-Draft Peering Data February 2008
Information Object (PIO) for GIST intended to carry NSLP-specific
peering data.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Peering Information Object . . . . . . . . . . . . . . . . . . 3
3.1. Fallback Method . . . . . . . . . . . . . . . . . . . . . 5
4. GIST API Issues . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Changes since version -00 . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Manner, et al. Expires August 28, 2008 [Page 2]
Internet-Draft Peering Data February 2008
1. Introduction
The General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp]
provides a signaling transport service to NSIS Signaling Layer
Protocols (NSLP). When an NSLP application wants to send a message
to its next peer, GIST starts setting up a Routing State (RS) by
sending a GIST Query message. This message carries the NSLP
identifier (NSLP ID) and Message Routing Information (MRI) among
others. The receiving GIST node running the same NSLP provides the
MRI to the NSLP application and requests it to make a decision on
whether to peer with the querying node.
The MRI carries very little information about the session that is to
be set up, about the querying node, or its real intentions towards
the signaling set up. It would be most beneficial to be able to
include additional peering information to the receiving node. This
would allow an NSLP application to make a better decision on whether
the session should actually be set up with the querying node, or
perhaps another one.
This specification presents a Peering Information Object (PIO) for
GIST that can be used by NSLP applications to give more information
for the NSLP at the responding node about the session being set up.
The content of the PIO is opaque to GIST and only carried in GIST
Query messages when setting up or refreshing Routing State. Since a
Query is not protected in any way, the content of the PIO is not
protected either. Since the content is NSLP-specific, it is possible
to use various hashes and shared encryption keys between NSLP nodes
to protect this data. Any such mechanisms are out of scope of this
specification, and do not affect GIST.
2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
All other terminology is taken from the GIST specification
[I-D.ietf-nsis-ntlp].
3. Peering Information Object
The Peering Information Object (PIO) carries NSLP-specific data to
help conditional peering decisions at the NSLP application in the
responding node. The PIO object is carried in GIST Query messages.
Manner, et al. Expires August 28, 2008 [Page 3]
Internet-Draft Peering Data February 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peering data //
+---------------------------------------------------------------+
The value for the Type field comes from shared GIST object type
space. The Length field is given in units of 32 bit words and
measures the length of the Value component of the TLV object (i.e. it
does not include the standard header).
Type: 0x0b (TBD by IANA)
Length: Variable
The leading two bits of the TLV header are used to signal the desired
treatment for objects whose Type field is unknown at the receiver
[I-D.ietf-nsis-ntlp]. The following three categories of object have
been identified, and are described here.
AB=00 ("Mandatory"): If the object is not understood, the entire
message containing it MUST be rejected with an "Object Type Error"
message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object").
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted
and the rest of the message processed as usual.
AB=10 ("Forward"): If the object is not understood, it MUST be
retained unchanged in any message forwarded as a result of message
processing, but not stored locally.
The AB-flags SHOULD have a value of "00" when used with the Peering
Information Object. Any other value would result in an undesirable
result, specifically:
1. AB=01 ("Ignore"): The RS is set up but the peer NSLP will not
know that the Peering Information was not honored. Thus, the
peering decision was made with less information than originally
intended. Subsequent peering decisions will also be made with
limited information. No indication is given to subsequent NSLP
nodes on the path that peering data was originally given by the
signaling initiator.
2. AB=10 ("Forward"): Same as above, but subsequent peering
decisions may or may not be based on the peering data. The
signaling initiator has no control of how the peering decisions
Manner, et al. Expires August 28, 2008 [Page 4]
Internet-Draft Peering Data February 2008
are done downstream.
With the value of "00", a peer node that does not support the Peering
Information object will return an "Object Type Error" to the sender.
This can then be used by the querying node to inform the NSLP that
peering data can not be used. Currently, the GIST specification
leaves it somewhat open as to which errors are propagated to the
NSLP. The error in understanding the PIO object SHOULD be provided
by GIST to the NSLP. Otherwise the querying NSLP node will not know
why the session was not set up, and can not, e.g., try a fallback
mechanism and set up a session without additional peering data.
GIST implementations SHOULD include a Peering Information Object
within GIST Query messages just after the possible NSLP Data object,
if such data was provided by application via NSLP API. GIST SHOULD
store the PIO for Query retransmissions. Stored PIO may also be
needed after the peering process completes. GIST implementations
SHOULD enable replacing the NSLP provided PIO. The NSLP can give a
new PIO to replace the old PIO for a given routing state. This new
PIO SHOULD be used when sending GIST Query messages, but change of
PIO does not mean any change in routing state validity. Application
SHOULD also be allowed to remove PIO by providing an empty PIO via
the NSLP API.
At this stage this specification does not support stacking of PIO
objects. Thus, if an NSLP needs to include complex peering data, it
can do so by encoding the structure within the PIO object data. The
content of the PIO is opaque to GIST, same as with the NSLP Data.
Note that GIST fragmentation rules apply. Thus, the peering data
must be limited in size to keep the size of GIST Query messages under
the MTU derived by GIST. If the size of a GIST Query message exceeds
the MTU, GIST SHOULD notify the NSLP about the issue. This allows
NSLP to take appropriate action, e.g., it may reduce PIO size.
When using D-Mode, it is possible that both a PIO and an NSLP Data
object would be included into a GIST Query. This may cause size of
the Query to exceed MTU. When avoiding this type of MTU-related
issue, GIST SHOULD prioritize PIO over NSLP Data. It is left for
GIST implementations to decide when to switch to using C-Mode.
3.1. Fallback Method
This section is meant to give NSLP authors an idea how to work in a
mixed environment where PIOs are not always available. This section
is not normative.
NSLP Applications should be aware, that PIOs may not always be
Manner, et al. Expires August 28, 2008 [Page 5]
Internet-Draft Peering Data February 2008
available. When an NSLP uses the new Peering Information Object and
runs into a GIST implementation that does not support PIO, it can use
hop-by-hop NSLP layer forwarding to deliver NSLP Data to the correct
recipient. When using hop-by-hop as a fall-back method, also replies
are delivered hop-by-hop. In Figure 2 we see how handshake with PIO
fails, and how NSLP retries without PIO.
.---------------. .---------------.
| NSLP #1 | | NSLP #1 |
'---------------' '---------------'
(1) SendMessage w/PIO ^ ^
(5) SendMessage | | |
| | | |
V V (4) MsgStatus (7) RecvMessage
.---------------. .---------------.
| PIO GIST (Qn) | | GIST (Rn) |
'---------------' '---------------'
| | ^ | ^ ^
| | '--- (3) Error ---' | |
| | | |
| '--------- (2) Query w/ PIO ----------' |
| |
'---------------- (6) Query ----------------'
==============================================>
FLOW DIRECTION
Figure 2
1. NSLP Sends NSLP Data towards the flow destination with PIO.
2. GIST Sends a Query message to the network with the NSLP supplied
PIO.
3. The Responding GIST Node is unable to process the PIO and returns
an "Object Type Error" message to the Querying Node.
4. After maximum number of Query retransmissions, GIST sends an
error message to NSLP indicating the error in routing state
establishment.
5. NSLP Falls back to Non-PIO behavior, sending the NSLP Data
towards the flow destination without the PIO.
6. GIST Sends a Query to the network without a PIO.
7. GIST at Responding Node sends a message to the NSLP requesting a
peering decision.
4. GIST API Issues
GIST specifies several abstract API calls between the NSLP
applications. The SendMessage and RecvMessage calls need
Manner, et al. Expires August 28, 2008 [Page 6]
Internet-Draft Peering Data February 2008
modifications to support PIO for GIST Query messages. Support for
passing peering information data to GIST is added to SendMessage.
RecvMessage is modified to give the peering data to the local NSLP at
the responding node.
SendMessage ( NSLP-Data, NSLP-Data-Size, Peering-Information-Data,
Peering-Information-Data-Size, NSLP-Message-Handle, NSLPID,
Session-ID, MRI, SII-Handle, Transfer-Attributes, Timeout, IP-TTL,
GIST-Hop-Count )
o Peering-Information-Data: Data to support conditional peering
decisions. NSLP should provide this data every time it calls
SendMessage primitive. Non-existent Peering-Information-Data
means removal of any existing Peering Information Data from GIST
data structures.
o Peering-Information-Data-Size: Length of Peering Information Data.
RecvMessage ( NSLP-Data, NSLP-Data-Size, Peering-Information-Data,
Peering-Information-Data-Size, NSLPID, Session-ID, MRI, Routing-
State-Check, SII-Handle, Transfer-Attributes, IP-TTL, IP-Distance,
GIST-Hop-Count, Inbound-Interface )
o Peering-Information-Data: Data to support conditional peering
decisions.
o Peering-Information-Data-Size: Length of Peering Information Data.
5. Security Considerations
The peering data is sent in a GIST Query and is unprotected.
Therefore, NSLP nodes that want to include some additional peering
data for the receiver must understand that GIST is unable to hide the
content from third parties. Since the content of a PIO is NSLP-
specific, it is possible to use various encryption keys between NSLP
nodes to protect the content of the PIO from eavesdropping. The
details of any such mechanisms are out of scope of this
specification, and do not affect GIST.
6. IANA Considerations
This specification makes the following request to IANA:
Assign a new object value for the Peering Information object (PIO)
from the GIST object value space.
Manner, et al. Expires August 28, 2008 [Page 7]
Internet-Draft Peering Data February 2008
7. Normative References
[I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-15 (work in
progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Changes since version -00
Changes from version -00 include, but do not limit to:
o Several editorial adjustments
o More accurate terminology in the whole draft, for example "NSLP at
the responding node" vs. "receiving peer"
o More text about when GIST should store or remove stored PIOs
o More text about MTU issues
o Added a short section about fallback mechanism
Authors' Addresses
Jukka Manner
University of Helsinki
P.O. Box 68
University of Helsinki FIN-00014 University of Helsinki
Finland
Email: jmanner@cs.helsinki.fi
URI: http://www.cs.helsinki.fi/u/jmanner/
Lauri Liuhto
University of Helsinki
P.O. Box 68
University of Helsinki FIN-00014 University of Helsinki
Finland
Email: lliuhto@cs.helsinki.fi
URI: http://www.cs.helsinki.fi/u/lliuhto/
Manner, et al. Expires August 28, 2008 [Page 8]
Internet-Draft Peering Data February 2008
Nuutti Varis
University of Helsinki
P.O. Box 68
University of Helsinki FIN-00014 University of Helsinki
Finland
Email: nvaris@cs.helsinki.fi
Teemu Huovila
University of Helsinki
P.O. Box 68
University of Helsinki FIN-00014 University of Helsinki
Finland
Email: thuovila@cs.helsinki.fi
Manner, et al. Expires August 28, 2008 [Page 9]
Internet-Draft Peering Data February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Manner, et al. Expires August 28, 2008 [Page 10]