One document matched: draft-bless-nsis-est-mrm-01.txt
Differences from draft-bless-nsis-est-mrm-00.txt
NSIS Working Group R. Bless
Internet-Draft Univ. of Karlsruhe
Intended status: Standards Track July 7, 2008
Expires: January 8, 2009
An Explicit Signaling Target Message Routing Method (EST-MRM) for the
General Internet Signaling Transport (GIST) Protocol
draft-bless-nsis-est-mrm-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 January 8, 2009.
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 January 8, 2009 [Page 1]
Internet-Draft Explicit Signaling Target MRM July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Explicit Signaling Target MRM . . . . . . . . . . . . . . . . 5
2.1. Explicit Signaling Target MRI . . . . . . . . . . . . . . 6
2.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 8
2.3. MRM Requirements . . . . . . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Bless Expires January 8, 2009 [Page 2]
Internet-Draft Explicit Signaling Target MRM July 2008
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 January 8, 2009 [Page 3]
Internet-Draft Explicit Signaling Target MRM July 2008
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 January 8, 2009 [Page 4]
Internet-Draft Explicit Signaling Target MRM July 2008
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 January 8, 2009 [Page 5]
Internet-Draft Explicit Signaling Target MRM July 2008
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 its use is currently not recommended.
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 January 8, 2009 [Page 6]
Internet-Draft Explicit Signaling Target MRM July 2008
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 January 8, 2009 [Page 7]
Internet-Draft Explicit Signaling Target MRM July 2008
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 January 8, 2009 [Page 8]
Internet-Draft Explicit Signaling Target MRM July 2008
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.
2.3. MRM Requirements
Section 3.3. of [I-D.ietf-nsis-ntlp] mentions requirements on the
content of an MRM definition, that are discussed in this section.
"The format of the information that describes the path that the
signalling should take, the Message Routing Information (MRI).": This
specification describes the MRI format in Section 2.1. Since this
signaling message routing method is using an explicit target address
for the signaling destination (the Destination Signaling Address), as
well as the Flow Identifier of the data flow, it contains sufficient
information to determine the signaling path. The adjacent peer may
use the Flow Identifier information to determine the next explicit
signaling hop.
"A specification of the IP-level encapsulation of the messages which
probe the network to discover the adjacent peers. A downstream
encapsulation must be defined; an upstream encapsulation is
optional": This MRM is using an explicit target address for the
signaling destination, i.e., the adjacent peer. The IP-level
encapsulation is based on UDP normal encapsulation, i.e., the address
of the adjacent peer is explicitly written in the outer IP header.
There is no such thing as a downstream encapsulation since the EST
MRM may be used to route the signaling data sideways if compared to
the direction of the data flow (cf. forwarding of signaling messages
along (b) in Figure 2).
"A specification of what validation checks GIST should apply to the
probe messages, for example to protect against IP address spoofing
attacks. The checks may be dependent on the direction (upstream or
downstream) of the message.": This specification requires that a node
receiving a GIST message with an EST-MRI must check whether it has
one local address that matches the destination signaling address.
Other specific validation checks cannot be provided within this
specification as they depend on the determination algorithm of the
next signaling hop. Validation checks should be applied if possible,
but they are probably only possible within the NSLP.
"The mechanism(s) available for route change detection, i.e. any
change in the neighbour relationships that the MRM discovers. The
default case for any MRM is soft-state refresh, but additional
supporting techniques may be possible;" Basically, this MRM also uses
soft-state refresh and the NLI as indicator whether the adjacent peer
Bless Expires January 8, 2009 [Page 9]
Internet-Draft Explicit Signaling Target MRM July 2008
has changed. However, since signaling messages routed with the EST
MRM are explicitly addressed to nodes and not intercepted there
should be no re-routing events as GIST level. Re-routing events at
IP-level will be transparent unless they lead to disconnection of the
signaling target.
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. Acknowledgments
Part of this work was funded by Deutsche Telekom Laboratories and
developed in cooperation with T-Systems within the ScaleNet project.
6. References
6.1. 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.
6.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]
Bless Expires January 8, 2009 [Page 10]
Internet-Draft Explicit Signaling Target MRM July 2008
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
(work in progress), February 2008.
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E.
Shim, "Candidate Access Router Discovery (CARD)",
RFC 4066, July 2005.
[gistka] Bless, R., "NSIS-ka - A free C++ implementation of NSIS
protocols", July 2008,
<https://i72projekte.tm.uka.de/trac/NSIS/>.
Appendix A. Change History
Changes from -00 to -01:
o added Section 2.3
o added Section 5
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 January 8, 2009 [Page 11]
Internet-Draft Explicit Signaling Target MRM July 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.
Bless Expires January 8, 2009 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-22 19:57:14 |