Network Working Group J. Manner Internet-Draft L. Liuhto Intended status: Standards Track N. Varis Expires: December 20, 2007 T. Huovila University of Helsinki June 18, 2007 Peering Data for NSIS Signaling Layer Protocols draft-manner-nsis-peering-data-00.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 December 20, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 receiving 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 December 20, 2007 [Page 1] Internet-Draft Peering Data June 2007 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 4. GIST API Issues . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Manner, et al. Expires December 20, 2007 [Page 2] Internet-Draft Peering Data June 2007 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 Query message. This Query 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 making a better decision on whether the session should actually be set up with this particular NSLP 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 receiving peer about the session being set up. The content of the PIO is opaque to GIST and only carried in a Query 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 mechanism is out of scope of this specification, and do not affect GIST either. 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 receiver. The PIO object is carried in a Query message. Manner, et al. Expires December 20, 2007 [Page 3] Internet-Draft Peering Data June 2007 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 NSLPs 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 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 December 20, 2007 [Page 4] Internet-Draft Peering Data June 2007 are done downstream. With the value of "00", a peer node that does not support the Peering Information object will return to the sender an "Object Type Error". 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. If, when using the new Peering Information Object, the NSLP runs into an unmodified GIST implementation, it can use hop-by-hop NSLP layer forwarding to deliver Messaging Application data to the correct recipient. When using hop-by-hop as a fall-back method, also replies are delivered hop-by-hop. GIST implementations SHOULD include a Peering Information Object within Queries just after the possible NSLP Data object, if such data was provided by application via NSLP API. GIST SHOULD store the PIO in case of resending a Query message is needed. Stored PIO may also be needed after the peering process, namely for Routing State refresh Queries. 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 of no concern 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 Query messages under the MTU. 4. GIST API Issues GIST specifies several abstract API calls between the NSLP applications. The SendMessage and RecvMessage calls need modifications to support passing peering data to GIST to be sent in the Query and at the receiving end to give the peering data to the local NSLP. The new updated API calls are as follows: 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 ) Manner, et al. Expires December 20, 2007 [Page 5] Internet-Draft Peering Data June 2007 o Peering-Information-Data: Data to support conditional peering decisions. 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 Query message. This means the data is unprotected. Therefore, NSLP nodes that want to include some additional peering data for the receiver must understand that GIST is unable to protect it. 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. 7. Normative References [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", draft-ietf-nsis-ntlp-13 (work in progress), April 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Manner, et al. Expires December 20, 2007 [Page 6] Internet-Draft Peering Data June 2007 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/ Nuutti Varis University of Helsinki P.O. Box 68 University of Helsinki FIN-00014 University of Helsinki Finland Email: nvaris@cs.helsinki.fi URI: http://www.cs.helsinki.fi/u/nvaris/ Teemu Huovila University of Helsinki P.O. Box 68 University of Helsinki FIN-00014 University of Helsinki Finland Email: thuovila@cs.helsinki.fi URI: http://www.cs.helsinki.fi/u/thuovila/ Manner, et al. Expires December 20, 2007 [Page 7] Internet-Draft Peering Data June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 December 20, 2007 [Page 8]