NSIS Working Group R. Bless Internet-Draft Univ. of Karlsruhe Expires: June 5, 2008 December 3, 2007 An Explicit Signaling Target Message Routing Method (EST-MRM) for the General Internet Signaling Transport (GIST) Protocol draft-bless-nsis-est-mrm-00 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 June 5, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The standard operation of the General Internet Signaling Transport (GIST) Protocol uses a path-coupled message routing method (PC-MRM) to find nodes interested in signaling message exchanges. This specification proposes an Explicit Signaling Target Message Routing Method (EST-MRM) in order to allow sending of signaling messages to explicit targets. Bless Expires June 5, 2008 [Page 1] Internet-Draft Explicit Signaling Target MRM December 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Explicit Signaling Target MRM . . . . . . . . . . . . . . . . 5 2.1. Explicit Signaling Target MRI . . . . . . . . . . . . . . 6 2.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 5.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Bless Expires June 5, 2008 [Page 2] Internet-Draft Explicit Signaling Target MRM December 2007 1. Introduction The standard operation of the General Internet Signaling Transport (GIST) Protocol [I-D.ietf-nsis-ntlp] uses a path-coupled message routing method (PC-MRM) to find nodes interested in signaling message exchanges. The assumption is that signaling involves the manipulation of state held in network elements along the flow's data path. The path-coupled signaling paradigm tries to ensure the alignment of control functions to the actual data path. For mobility environments seamless handovers are a desirable objective. If signaling takes place after a handover was performed, it will take some time until the state update has been completed. Thus, there exist proposals to start the signaling before the handover takes place and to use the current point of attachment for completion of the signaling process. This "anticipated handover" enables a pre-reservation of resources in a quality-of-service context for instance, i.e., for QoS NSLP signaling applications [I-D.ietf-nsis-qos-nslp]. Therefore, a resource reservation can be used immediately after the handover was performed. With the path-coupled MRM, however, such kind of optimization is impossible, since state should be established or manipulated along a data path that is not used yet, but probably will be in the future. Therefore, in order to support anticipated handovers a signaling message routing is required that is not strictly on path. In Figure 1 an example for an anticipated handover scenario is shown. If the mobile node (MN) is a data sender for flow f_o and has information that it may change its point of attachment from access A to access B, it starts signaling for resources along the new path that begins at B. First, the MN sends signaling messages to A and A will signal to B. B can then use path-coupled signaling in order to find the correct data path for the potential new flow f_n towards the CN. Since signaling messages are sent to A, but concerning f_n, a PC-MRM cannot be used. Similarly, the signaling between A and B is not path related and must be done explicitly. Bless Expires June 5, 2008 [Page 3] Internet-Draft Explicit Signaling Target MRM December 2007 CN | +-----+ / | \ | | | | | | Domain 4 \ | / +--|--+ | +--|--+ / | \ | #% | | # % | Domain 3 \ # % +--#--+ % # % +--#--+ % +-----+ / # \ %/ \ | # | | % | | # | | % | \ # / \ % / +-[A]-+ +-[B]-+ # Domain 1 Domain 2 # data flow f_o ##: MN->A->CN MN data flow f_n %%: MN->B->CN [A]: Access router A [B]: Access router B A handover scenario Figure 1 Figure 2 indicates the related signaling flows: (a): MN signals for flow f_n via its current access router A (b): Access router A signals towards the candidate access router B (c): On-path signaling for flow f_n starting from access router B (proxy mode) It is out of scope of this specification how the addressing information about the future flow f_n is obtained by the MN or how A determines the address of the candidate router B that must be signaled next. One possibility is to use the CARD protocol [RFC4066] or that some additional addressing information (such as MAC addresses of access points) is carried in the NSLP. Thus, it is also allowed to let the source address of f_n being unspecified if the MN has no knowledge about its actual future address. Since it can be assumed that B has enough information to determine the required address, it is then up to B to fill in the missing information for the flow Bless Expires June 5, 2008 [Page 4] Internet-Draft Explicit Signaling Target MRM December 2007 before continuing with the path-coupled signaling in (c). CN | +-----+ / | \ | | | | | | Domain 4 \ | / +--|--+ | +--|--+ / | \ | # | | # \\ | Domain 3 \ # \\ +--#--+ \\ # \\ +--#--+ \\ +-----+ / # \ \\ \ | # | | \\ | | # | | (c) | \ # / \ || / +-[A]=====(b)=====>[B]-+ /$\ $ Domain 1 Domain 2 $ (a) $$: signaling flow (a) $ ==: signaling flow (b) $ ||: signaling flow (c) MN Signaling in a handover scenario Figure 2 The Hypath proposal [I-D.cordeiro-nsis-hypath] defines a similar MRM for QoS signaling between off-path resource control elements like bandwidth brokers. It is for further study, how the EST-MRI can be unified with the Hypath proposal. 2. Explicit Signaling Target MRM In order to support cases like the ones described in the introduction, this document proposes the specification of an Explicit Signaling Target MRM (EST-MRM). Bless Expires June 5, 2008 [Page 5] Internet-Draft Explicit Signaling Target MRM December 2007 The EST-MRM uses a normal encapsulation for Query messages, i.e., UDP encapsulation with the destination default port for GIST and the destination IP address set to the next signaling hop. The source IP address SHOULD be set to the signaling source address of the node who is sending the message. EST-MRM routed Query messages do not have to be intercepted but are explicitly routed to their next (or final) signaling destination. In contrast to the EST-MRM, the path-coupled MRM requires Query messages to be sent with Q-mode encapsulation that is using a router alert option. Furthermore, implementations must be aware, that Query messages may use with a different encapsulation method than Q-mode encapsulation, i.e., the check for wrong encapsulation MUST consider the particular MRM that is being used. The EST MRM defines an EST Message Routing Information (EST-MRI) object that contains information about the actual data flow that is being signaled as well as addressing information for the signaling message routing and transport itself. A node receiving a GIST message with an EST-MRI must check whether it has one local address that matches the destination signaling address. If it is not the case, it should forward the GIST message basically unchanged towards the signaling destination address, only with a decremented GIST Hop Count. Thus, even if the message gets intercepted by accident, it will be forwarded to the final signaling destination. It is up to the signaling application's logic to determine the next signaling hop. Usually, it will be related somehow to the given data flow, e.g., the signaling target will be along a flows data path. In the particular example of the anticipated handover, signaling targets are the current access router as well as the candidate access router that is presumably the next ingress node for the data flow. When transmitting a signaling message with the EST-MRI, the outer IP destination address SHOULD be set to the destination signaling address of the EST-MRI. In principle it is also possible to forward the signaling message to a node that is not the final destination signaling node. In this case, the destination signaling address and the IP destination address are not the same. This allows to let the signaling take multiple intermediate hops. This mechanisms is, however, for further study and currently not recommended to use. 2.1. Explicit Signaling Target MRI The EST-MRI object (Figure 3) starts with the common MRI header (cf. section A.3.1 of [I-D.ietf-nsis-ntlp]) and carries a data flow address description that is identical to the one that is defined in the Path-coupled MRI (PC-MRI). In addition to that it carries at Bless Expires June 5, 2008 [Page 6] Internet-Draft Explicit Signaling Target MRM December 2007 least information about the origin signaling address and the destination signaling address, which are usually identical to the IP source and IP destination address of the UDP encapsulated signaling message. Furthermore, it may contain an additional IP address of a network node where the data flow, which is described by the PC-MRI, enters the network. It is necessary to provide this information in some cases since the currently deployed routing protocols can only determine the next hop in direction towards the destination, but not backwards towards the source. Thus, this information must be provided to the next hop in most cases. The EST-MRI object has the following layout: EST-MRI= MRI-header PC-MRI EST-Control Origin-Signaling-Address Destination-Signaling-Address [ Ingress-Node-Address ] Layout of the Explicit Signaling Target Message Routing Information Figure 3 The binary representation is shown in Figure 4. First, it contains the normal data flow address descriptor that is required for path- coupled signaling. The latter is necessary so that an RMF can determine the path of the data flow that is being signaled for. If the initiator cannot predict its future address, it is allowed to set the source IP address in the PC-MRI to unspecified (either 0.0.0.0 or ::). After the PC-MRI, an EST-Control field is provided, that provides further information on the following fields or their interpretation respectively. In addition to this description three IP addresses may be provided. The Origin Signaling Address is the address of the node who initiated the signaling. The Destination Signaling Address is the address of the signaling peer that should receive the signaling message. Both Origin Signaling Address and Destination Signaling Address are mandatory to specify. They may be both either IPv4 or IPv6. The actual type is given by the version field (IPVerS) in the high order EST-Control word. Providing the signaling addresses explicitly has several advantages: if the outer addresses are rewritten by a NAT or if the path-directed signaling is relayed via several hops before arriving at the final peer. The Ingress Node Address is optional to specify. When not present, the version field (IPVerI) of the low order word in the EST-Control field must be set to 0. Otherwise IPVerI will indicate the protocol version of the address. It may have a different type than the Origin Bless Expires June 5, 2008 [Page 7] Internet-Draft Explicit Signaling Target MRM December 2007 Signaling Address or the Destination Signaling Address, but must have the same type as the address pair in the PC-MRI flow address descriptor. Mismatching versions must be rejected with an "MRI ValidationFailure" error message with subcode 1 ("IP Version Mismatch"). The Ingress Node Address is necessary to specify in some scenarios, because the RMF cannot determine a flow path in the reverse direction, except for very simple topologies. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IP-Ver |P|T|F|S|A|B|D|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Source Address // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Destination Address // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Prefix | Dest Prefix | Protocol | DS-field |Rsv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Reserved | Flow Label : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : SPI : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Source Port : Destination Port : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPVerS| Reserved | IPVerI| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Origin Signaling Address // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Destination Signaling Address // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Ingress Node Address // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 The MRI common header carries the N-flag and SHOULD be 0 for this MRM. A NAT may have to translate at least one of the Origin Signaling Address, the Destination Signaling Address, or the Ingress Node Address. Depending on the signaling scenario it may also have to translate the contained PC-MRI information (for signaling messages along (a) and (b) in Figure 2 this is usually not required). 2.2. Implementation The EST-MRI was implemented and tested successfully in the GIST-ka implementation [gistka]. Thanks to the object oriented design of the protocol itself and also the implementation, the implementation Bless Expires June 5, 2008 [Page 8] Internet-Draft Explicit Signaling Target MRM December 2007 effort was quite low. It was shown that even MA re-use works across PC-MRM and EST-MRM flows, i.e., if some flows are signaled path- coupled and some are signaled explicitly, further signaling for both types can re-use existing messaging associations. 3. Security Considerations Basically, the security considerations of GIST apply. The main change is that Query messages are not sent using Q-mode encapsulation and that they contain a different MRI object. Since normal encapsulation is already considered by GIST, no new security considerations are necessary. Even for initial Query messages with an EST-MRI, the usual mechanisms like authorized peer database checking and late state installation mechanisms apply. 4. IANA Considerations According to section 9 of [I-D.ietf-nsis-ntlp] this specification requires assignment of a new MRI-ID. Until an assignment happens by IANA, it is suggested to use MRI-ID 125 for the EST-MRM. 5. References 5.1. Normative References [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", draft-ietf-nsis-ntlp-14 (work in progress), July 2007. 5.2. Informative References [I-D.cordeiro-nsis-hypath] Cordeiro, L., "GIST Extension for Hybrid On-path Off-path Signaling (HyPath)", draft-cordeiro-nsis-hypath-04 (work in progress), July 2007. [I-D.ietf-nsis-qos-nslp] Manner, J., "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-15 (work in progress), July 2007. [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005. Bless Expires June 5, 2008 [Page 9] Internet-Draft Explicit Signaling Target MRM December 2007 [gistka] Bless, R., "NSIS-ka - A free C++ implementation of NSIS protocols", November 2007, . Author's Address Roland Bless Institute of Telematics, Universitaet Karlsruhe (TH) Zirkel 2 Karlsruhe 76131 Germany Phone: +49 721 608 6413 Email: bless@tm.uka.de URI: http://www.tm.uka.de/~bless Bless Expires June 5, 2008 [Page 10] Internet-Draft Explicit Signaling Target MRM December 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). Bless Expires June 5, 2008 [Page 11]