Network Working Group A. McDonald Internet-Draft R. Hancock Expires: July 24, 2003 E. Hepworth Siemens/Roke Manor Research January 23, 2003 Design Considerations for an NSIS Transport Layer Protocol draft-mcdonald-nsis-ntlp-considerations-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 July 24, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract A framework for NSIS is in preparation, and will identify a split into two layers. The lower layer, referred to as the NSIS Transport Layer Protocol (NTLP) provides generic support for different types of path coupled signalling, including QoS signalling. This document discusses issues to be considered in the design of an NSIS Transport Layer Protocol (NTLP). McDonald, et al. Expires July 24, 2003 [Page 1] Internet-Draft NTLP Design Considerations January 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Transport Functionality Issues . . . . . . . . . . . . . . . 3 2.1 Congestion Avoidance . . . . . . . . . . . . . . . . . . . . 4 2.2 Message Bundling . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Message vs. Stream based transports . . . . . . . . . . . . 5 2.4 Message fragmentation . . . . . . . . . . . . . . . . . . . 5 2.5 Message reordering and Head of line blocking . . . . . . . . 6 2.6 Duplicate Message Detection . . . . . . . . . . . . . . . . 6 2.7 Lossless Transport and Loss Detection . . . . . . . . . . . 6 2.8 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Routing and Discovery . . . . . . . . . . . . . . . . . . . 7 3.1 Peer Discovery . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Path Discovery . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Capability Discovery . . . . . . . . . . . . . . . . . . . . 8 3.4 Path Divergence . . . . . . . . . . . . . . . . . . . . . . 8 3.4.1 Signalling/Data Path Divergence . . . . . . . . . . . . . . 8 3.4.2 Path Divergence Through Rerouting . . . . . . . . . . . . . 9 4. NAT and Firewall Traversal . . . . . . . . . . . . . . . . . 10 5. State Location . . . . . . . . . . . . . . . . . . . . . . . 10 6. Overload Protection . . . . . . . . . . . . . . . . . . . . 12 7. Failure detection and Failover . . . . . . . . . . . . . . . 12 8. Feedback/Error Messages . . . . . . . . . . . . . . . . . . 12 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1 Message Protection . . . . . . . . . . . . . . . . . . . . . 14 9.2 Denial of Service Protection . . . . . . . . . . . . . . . . 14 10. Message Objects and Extensibility . . . . . . . . . . . . . 14 11. Other Functionality . . . . . . . . . . . . . . . . . . . . 15 11.1 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.2 Inter/Intra Domain Use . . . . . . . . . . . . . . . . . . . 15 11.3 Mobility Support . . . . . . . . . . . . . . . . . . . . . . 15 11.4 Session/State Identification . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 McDonald, et al. Expires July 24, 2003 [Page 2] Internet-Draft NTLP Design Considerations January 2003 1. Introduction This document assumes the framework as discussed in [1]. In particular, the NSIS framework defines high level issues of how the NTLP overall interacts with other protocols (e.g. routing and mobility issues) and how it is used to support signalling applications, and defines the overall functionality that the NTLP should support. (The precise functionality required of the NTLP has not been finally defined, and might be impacted by some of the design considerations given here. It is always possible to argue that a particular design question is irrelevant since the corresponding function is not necessary in the first place.) The focus for this document is primarily internal aspects of the NTLP design, although these can be strongly influenced by usage scenarios (especially in performance aspects). Overall requirements for signalling protocols are given in [2]. The original proposal for a split layer signalling protocol has been given in [9], which also contains extensive discussion of the design rationale for CSTP, which is the proposed NTLP there. There are additional proposals for the NTLP with accompanying design rationale, e.g. CASP [11] and direct re-use of RSVP [12]. The purpose of this document is not to analyse all the design options and fix a particular approach for the NTLP, but initially simply to consolidate the questions and issues that have to be considered. The pattern for the sections in this document is something like: o Identify issues that the NTLP must address o Identify some of the applicable techniques and their implications o Illustrate how these techniques relate to using existing protocols (especially the case of RSVP) 2. Transport Functionality Issues This section considers 'traditional' transport layer functions such as reliability, congestion management and so on. In the NSIS protocol suite, these functions are primarily the responsibility of the NTLP. One overall question when considering transport layer issues is: should we use an already existing, standard transport protocol (e.g. TCP or SCTP) or not? Do different parts of the NTLP behaviour have different requirements? McDonald, et al. Expires July 24, 2003 [Page 3] Internet-Draft NTLP Design Considerations January 2003 And, consequently do different parts of the NTLP require different choices to be made about whether to use a standard or custom transport protocol? Usability of existing transport layers for AAA traffic is analysed in [14] and some of the same issues may be relevant here. A significant issue for deciding what transport functionality the NTLP should provide is that communication between NSLP peers might be performed over a single NTLP hop, or a series of concatenated NTLP hops (if there are intervening NSIS entities which do not process the relevant signalling application). In the former case, rigorous end-to-end thinking pushes more functionality out of the NTLP and into the NSLP. 2.1 Congestion Avoidance The NTLP must provide congestion control mechanisms (e.g. as described in [6]). This might be provided in a specialised way as part of a custom protocol directly over IP. Alternatively, an existing protocol which already provides congestion control, such as TCP or SCTP might be used to carry NTLP. The base RSVP protocol contains no congestion control mechanism. Exponential back-off procedures for RSVP are described in section 6 of RFC2961 [7]. If using TCP or SCTP, will the standard transport parameter estimation algorithms function correctly? More generally, does signalling have specialised requirements for congestion handling (and if it does, is it signalling application specific? - in which case, should this reside in the NSLP rather than the NTLP?) 2.2 Message Bundling There are two aspects to the possible provision of bundling in relation to the NTLP. Should a single NTLP PDU be able to carry multiple NSLP PDUs (including from different, possibly unrelated, signalling applications)? Should it be possible to bundle multiple NTLP PDUs into a single IP datagram (or TCP segment, or SCTP chunk)? Note that unless bundling is done only for messages relating to flows between the same endpoints (which would be a very restrictive case), bundling almost necessarily involves direct ('peer-to-peer') addressing and hence means additional consideration must be given to prevention of path divergence (see Section 3.4). In order to reduce the per signalling PDU overhead, a message bundling mechanism is provided within RSVP [7]. Because of the McDonald, et al. Expires July 24, 2003 [Page 4] Internet-Draft NTLP Design Considerations January 2003 divergence issue, the restriction is made that they can only be used between direct RSVP neighbours, in order to avoid unnoticed path divergence as described in Section 3.4. (This suggests the need for an explicit discovery of whether the next node is a direct neighbour.) How likely is it that NSLP peers will be direct NTLP peers (as compared to being separated by more than one NTLP 'hop')? If an existing transport protocol is used under the NTLP, then message bundling may exist as part of that protocol. Both TCP and SCTP support the use of Nagle's algorithm [3] (or a similar technique), which allows pieces of data from higher layers to be 'bundled' into a single IP packet. Is such a technique appropriate for NSIS messages? (In particular, are the timing rules implicit in these algorithms appropriate for signalling messages?) 2.3 Message vs. Stream based transports The NTLP is message orientated by nature. If it is carried over a stream-based transport such as TCP then the NTLP needs to be able to split it out back into individual messages. If a datagram or message-based transport (such as SCTP, IP or UDP) is used then this provides the necessary message framing already. The separate issue of upper layer multiplexing is covered in Section 10. 2.4 Message fragmentation The NTLP must be capable of performing message fragmentation when the amount of data in a message to be sent is larger than can fit into a single IP packet (or a single sensibly-sized IP packet). This may occur, for example, where certificates are carried in order to support authentication functions, and also in order to support features of future NSLPs. IP fragmentation might be used to provide the NTLP message fragmentation. In this case the protocol must perform Path MTU Discovery for IPv6 and should support it for IPv4. (If end-to-end addressing was used, it is not clear that Path MTU discovery would function correctly, e.g. if an NSIS entity which was not one of the flow endpoints needed to perform it.) IP fragmentation is only supported end-to-end in IPv6. If TCP or SCTP is used to carry NTLP messages, then fragmentation/ segmentation is provided by these protocols, and PMTU-D can be expected to be supported as standard. McDonald, et al. Expires July 24, 2003 [Page 5] Internet-Draft NTLP Design Considerations January 2003 2.5 Message reordering and Head of line blocking Can messages arrive out-of-order at the NTLP from lower layers (e.g. if the NTLP is carried directly over IP or UDP)? If so, does it matter at the NTLP? Does the NTLP need to be able to re-order the messages correctly? Does the NTLP have to guarantee to pass messages in order to the local NSLP? Or, should it be left to the NSLP to decide whether to process, re-order or drop messages? How generic to signalling applications is the requirement for in-order delivery? In addition, would head-of-line blocking be a problem for the NSIS protocols? TCP could used to carry NTLP messages. One way to use it would be to have a single TCP connection between each pair of NSIS peers, but this would result in head-of-line blocking (across multiple signalling sessions). Could more than one TCP connection be used to mitigate this? SCTP is another alternative for carrying NTLP messages. SCTP supports multiple streams within an association. SCTP also supports reliable delivery of out of order delivery of messages (though this feature is unavailable when TLS is being used). In the base RSVP protocol there are no sequence numbers in the messages. Consequently there is no method to detect out-of-order delivery or duplicate messages. Out-of-order delivery can still be allowed when the RSVP Cryptographic Authentication mechanism [5] is used, although replay protection is provided. 2.6 Duplicate Message Detection Do we care about receiving duplicate messages at the NTLP, or is this purely an NSLP problem? Are security concerns about message replay addressed? (see Section 9). 2.7 Lossless Transport and Loss Detection How is identification of message loss and/or retransmission provided? Should the NTLP actually provide true lossless transport end-to-end, or simply local recovery (peer-to-peer) from messages which can be detected to have been dropped (e.g. because of congestion)? McDonald, et al. Expires July 24, 2003 [Page 6] Internet-Draft NTLP Design Considerations January 2003 2.8 Other Issues It may be useful for lower layer information to be visible at the NTLP. For example, changes in the TTL of received packets may be an indication that a route change has occurred, or the TTL may need to be controlled explicitly. Given existing implementation constraints, does this have implications for what encapsulation should be used (e.g. does it imply the use of raw IP sockets)? 3. Routing and Discovery 3.1 Peer Discovery Addressing of NTLP messages can be peer-to-peer or end-to-end, as discussed in section 3.3.4 of [1]. Peer discovery in the data receiver to sender direction is not required (see the sender/receiver oriented issues discussed in [10]). In the downstream direction, the NTLP is required to perform peer discovery (at least implicitly), in addition to transporting NSLP messages along the data path. Are the messages for discovery integrated into the rest of the NTLP protocol? Or, is the discovery mechanism separated from the transport of NSLP messages, for example, as a dedicated message exchange? Should the NTLP be able to accept alternative source of information about which peer to talk to? For the discovery mechanism, how similar are the signalling and data messages? (see discussion in Section 3.4). Some NTLP entities also terminate the signalling transport (e.g. when acting as a proxy on behalf of an end-system). How do you detect that you are the last NTLP entity before the data receiver? What if there are more NTLP entities, but none with the relevant NSLP? RSVP uses end-to-end addressing in some of its messages, and makes use of the IPv4 router alert option (or IPv6 hop-by-hop option) to inform routers that they should intercept and process the messages. Further details are discussed in section 4.1 of [1]. 3.2 Path Discovery The NTLP does not provide an explicit topology or path discovery service to the NSLP. It does, however, carry out implicit path discovery simply by being able to route from one NTLP hop to the next. Is the state necessary for backwards routing stored locally at each McDonald, et al. Expires July 24, 2003 [Page 7] Internet-Draft NTLP Design Considerations January 2003 node, or carried in route record objects (see further discussion in Section 5). 3.3 Capability Discovery The NTLP needs to consider Capability Discovery and/or Exchange and/ or Agreement. What sort of things appear as "capabilities"? - signalling applications (i.e. NSLPs), types of signalling application, supported features, options, etc? RSVP can use AdSpec objects to learn information from nodes along a path primarily for QoS purposes, although the same mechanism could be generalised for other purposes. There is no mechanism for learning about the capabilities, security mechanism, supported security options, identity, etc of peers. What is the split between the NTLP and NSLPs for capability discovery mechanisms? What form do the "capabilities" take? 3.4 Path Divergence Two forms of path divergence must be considered. Firstly, path divergence may occur when NSIS signalling is sent down a different route to the main data flow, for example due to policy forwarding being used to select the route for the data flow. Secondly, path divergence may occur during the life of a reservation when rerouting occurs, with the data flow going down a new path, but signalling state persisting on the old path, and possibly signalling messages continuing to use the old path. 3.4.1 Signalling/Data Path Divergence Divergence may occur when policy forwarding is used which takes account of protocol, transport layer ports, DSCP, etc. in determining the route for packets. This is of most concern when the initial signalling connections are being established, but is also of relevance when rerouting of the data flow occurs. Therefore, the manner in which this should be addressed in the NTLP needs to be considered. Can path divergence be reduced at NSIS-aware nodes, since the node knows about both the data flow and the NSIS signalling messages? i.e. can it look at the flow identifier in the NTLP messages and calculate the next hop directly from this, rather than constructing the NTLP message and then routing normally? At NSIS-unaware nodes performing policy forwarding the data and signalling flows are more likely to diverge since the node is unaware McDonald, et al. Expires July 24, 2003 [Page 8] Internet-Draft NTLP Design Considerations January 2003 that they are related. The only real countermeasure is to make the path selecting messages of the NSIS protocol look as much like the data flow packets as possible (e.g. same source/destination addresses, same DSCP, etc.). The RSVP protocol does not attempt to directly tackle this form of path divergence in the case of policy forwarding. How should the NTLP tackle this form of path divergence? For example, should the 'discovery' messages be made to look like the data flow? 3.4.2 Path Divergence Through Rerouting When rerouting occurs the signalling data may continue to be sent along the old route (particularly if signalling data is addressed directly between NSIS peers). The NTLP should be capable of detecting this and performing rerouting as required. How should NSIS entities detect route changes, and how quickly should they react? Some RSVP messages, such as Path messages, are addressed to the data destination, and can usually be used to detect when rerouting of the signalling path has occurred. RSVP assumes that this indicates also a rerouting of the data flow. In other cases (e.g. Resv and Bundle messages), the RSVP messages are addressed directly to an RSVP neighbour. These cannot detect route changes. In fact, it is forbidden to use Bundle messages when changes in the next hop cannot be detected. Since an NSIS capable router would also have the related data traffic passing through it, can it use this information to detect when this data flow 'disappears' due to rerouting and determine that the data path has changed? How should the NTLP work to ensure timely identification of route changes to a data flow? Possibilities for route change identification include: o Local detection (e.g. routing local repair) o Remote detection (e.g. by signalling application) o Sending of (un-bundled) downstream signalling messages (basic RSVP approach) o Sending explicit signalling to verify the next peer identity (CASP approach) McDonald, et al. Expires July 24, 2003 [Page 9] Internet-Draft NTLP Design Considerations January 2003 How should the NTLP react to data path changes? Should the protocol explicitly define the state management (e.g. hold-down timers) necessary to prevent spurious signalling, or should it assume this is done 'externally' and react promptly itself? e.g. RSVP message processing rules include such rules for processing Path messages to mitigate route flapping problems. On the other hand, if the route change is caused by a mobility event [13] a prompt reaction is essential. Should the NTLP include different variants of peer discovery messages to handle this type of issue? Is the selection of a variant influenced by the NSLP being used? 4. NAT and Firewall Traversal The NTLP/NSLP carry flow identifying information in their payloads. This causes some 'NAT-unfriendliness', since the NAT must change these payloads to reflect the way it has (or will) translate the data flows. For correct NAT traversal of RSVP packets the NAT must be able to understand a number of RSVP object classes, including session objects, hop objects, error specification objects, filter specification objects, reservation confirmation objects. NAT issues for RSVP are discussed in section 4.2 of [8], where the need for an RSVP-ALG (Application Layer Gateway) is identified, as is the fact that this will not work when RSVP Integrity objects are being used. Is it desirable to be able to support NSIS-aware NATs without them requiring full NSIS support with a MIDCOM NSLP, and when NTLP is being used for a flow without using a MIDCOM NSLP (i.e. when using NSLPs other than MIDCOM)? Is it desirable to place any objects that may need to be manipulated by the NAT in the NTLP, so that new NSLPs can be defined without requiring modifications to the NAT? If the NTLP is carried over TCP or SCTP, then flow state can be expected to already be handled in most NATs and stateful firewalls. Will an NTLP-ALG or NTLP entity in the NAT be used to perform the translation on flow identifiers carried by the protocol? 5. State Location The NSIS protocols will establish state along the signalling path. One component of this is application state (which is relevant to the NSLP). Also, there may be message transport state (which could be hidden inside the NTLP). How are these state components related, and what dependencies are there between the two parts? McDonald, et al. Expires July 24, 2003 [Page 10] Internet-Draft NTLP Design Considerations January 2003 Should the NTLP be directly or indirectly involved in managing NSLP state? What state should be held in the NTLP (if any)? And, what state should be held by the various NSLPs? Should state held at the NTLP be soft state? Can multiple NSLP states (from a single NSLP or different NSLPs) be associated with a single NTLP "session"? What is the relationship between the state lifetime at the NTLP and NSLP? The concept of a split between 'NTLP' and 'NSLP' parts does not exist in RSVP, so no prior implementation or design experience can be gleaned from RSVP on this issue. It is necessary to consider where to put state in the network. For this it is necessary to consider whether the NTLP should be optimised for (a) low latency at signalling start-up, or (b) low latency on route changes. Based on the answer to that question, the protocol might need to keep state either (a) at the edge of the network, or (b) in the core (i.e. close to where the change occurs). NTLP state identified within this draft, includes: o Peer state, which includes: * Presence * Capabilities * Status * Negotiated parameters o Routing state, including: * Next hops * Previous hops o Security related state o Session and flow identification o NTLP configuration, such as: * State for duplicate detection * Data for potential retransmission McDonald, et al. Expires July 24, 2003 [Page 11] Internet-Draft NTLP Design Considerations January 2003 * RTT for congestion control * Path MTU How much state is needed for the protocol to work? How much state is needed for the protocol to work efficiently? How much state is needed for the error handling? Should the NTLP do any merging of states/messages itself? Does the NTLP perform "lazy forwarding" (e.g. in the style of RSVP with refresh reduction, where messages representing a state change are forwarded immediately, but refreshes can be sent as part of a summary refresh)? Or, are these NSLP issues? In particular, if the NTLP does not perform state management, then it cannot offer this type of functionality. 6. Overload Protection Protection against overload caused for malicious purposes is discussed in Section 9.2. What mechanisms should the NTLP provide to protect against overload during normal use? What overload protection capability the NTLP should provide as part of the service for NSLPs? For example, should it provide flow control? 7. Failure detection and Failover The handling of re-routing to avoid path divergence is discussed in Section 3.4.2, and has different requirements to the need to handle NTLP failures. Should the NTLP be able to detect and handle failures (e.g. lost NTLP entities) itself? Even if the NTLP does not perform failover itself, should it be designed to allow easy failover by an NSLP? What are the constraints on the NTLP that come from this? Is a technique similar to the BGP Graceful Restart appropriate to avoid rerouting and route flap when an NSIS entity restarts? 8. Feedback/Error Messages McDonald, et al. Expires July 24, 2003 [Page 12] Internet-Draft NTLP Design Considerations January 2003 What error conditions are relevant at the NTLP? The NSIS protocols must support "transport" related errors and NSLP (e.g. QoS) errors. RSVP does not make a (structural) distinction between the two. An example of an NTLP to NSLP (i.e. generated by an NTLP but consumed by an NSLP) error message is an 'NSLP unreachable' message. It may be that this is the only NTLP to NSLP error message, with other error messages being either NTLP to NTLP or NSLP to NSLP. Should the NTLP provide error handling functions on behalf of the NSLPs? Or, must an NSLP handle errors itself? What about ICMP errors (e.g. where an NTLP message is sent to a node that doesn't support NTLP)? Are these correctly addressed? For example, consider the case where an intermediate node between two end-points sends out a message with the end-point addresses as the source and destination (to avoid path divergence). What happens if this results in an ICMP error message from further downstream? (This error message will be sent to the source, but is actually of interest to the intermediate node.) How are ICMP errors processed in relation to the NTLP? (e.g. consider UDP related ICMP port unreachable vs TCP RST processing) Are errors sent hop-by-hop or not? For some types of error only the originator of the message to which the error is a response should process the error, in other cases it may be desirable for error messages to affect state at intermediate entities. The latter requires hop-by-hop error handling, the former case can be handled either hop-by-hop or by direct addressing to the message originator. An example of non-hop-by-hop message is the Notification message in RSVP-TE which is transmitted directly to the source. Is there a distinction between an NSLP path teardown and an NTLP session termination? Does removing (for example) QoS reservation state automatically remove path state, or is an explicit path teardown required? Does a path teardown remove reservation state automatically? 9. Security It is assumed that at the NTLP layer the only security concerns are for message protection and overload protection (protection against malicious traffic), including the internal or external key management mechanisms to support this. McDonald, et al. Expires July 24, 2003 [Page 13] Internet-Draft NTLP Design Considerations January 2003 It should be noted that the security mechanisms for the NTLP are contingent on other aspects of the design. 9.1 Message Protection Should the NTLP use an existing security mechanism (e.g. IPsec or TLS)? Or, should a new security mechanism be developed for the NTLP (e.g. in the style of the RSVP integrity mechanism)? Should we reuse an existing key exchange protocol, or write our own? (e.g. if rolling our own integrity protection mechanism) How much flexibility does the security mechanism need to have? Should the NTLP protocol specify a single solution for the complete security problem? Or, are some parts of the NTLP operation different to others (and so need different security mechanisms)? How are nodes identified? How is identity information securely exchanged? 9.2 Denial of Service Protection Should the NTLP provide protection against flooding attacks itself? Or, is it sufficient to rely on lower layers (e.g. SCTP cookies, IKE cookies)? Who is made to "work hard" during an attack? Is the flooder made to suffer in any way? Where does the "attack" come from (e.g. can it be forwarded down a series of NSIS entities)? Are the initial messages sufficiently cheap that such attacks have little effect (e.g. what state do they create)? 10. Message Objects and Extensibility It is currently undecided whether any of the RSVP objects [15] should be reused for the NTLP. The message formatting may be required to support new NTLP message types. Other protocols have used techniques such as marking objects "optional" or "critical" to provide support for this. RSVP allows unknown classes to be handled in different ways: the entire message may rejected, the object may be ignored and not forwarded, or the object may be ignored and forwarded. Unknown types of object within a known class generally result in an error being sent back. However, certain objects which are opaque to RSVP (e.g. FLOWSPEC, ADSPEC, and POLICY_DATA) can be passed on to the relevant module for a decision to be made. McDonald, et al. Expires July 24, 2003 [Page 14] Internet-Draft NTLP Design Considerations January 2003 The NTLP also needs to be able to handle new upper layer 'things'. It is an open question as to whether these are specified as new signalling applications, new types of signalling application, new capabilities, additional optional aspects of a signalling application, etc. An NTLP is expected to be able to support multiple signalling applications (e.g. QoS and MIDCOM). It is to be decided whether these must be supported at the same time (both in the same NTLP message, or both related to the same NTLP 'session' identifier). 11. Other Functionality 11.1 Scoping Is it necessary to be able to specify a scope for a message (or individual objects) in the NTLP? (Or, is the purely an NSLP concept?) 11.2 Inter/Intra Domain Use Are there different modes of operation for intra/inter domain use? How is this performed (e.g. having some functionality made optional and only used in a particular mode of operation)? 11.3 Mobility Support Mobility related issues are still to be considered. See [13] for some discussion. 11.4 Session/State Identification Issues relating session/state identification (including their relationship to flow identification) are still to be considered. 12. Security Considerations This design considerations document raises no security considerations in and of itself. Design considerations relating to the security of an NTLP protocol are given in Section 9. Informative References [1] Hancock, R. and I. Freytsis, "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-01 (work in progress), November 2002. [2] Brunner, M., "Requirements for Signaling Protocols", draft-ietf-nsis-req-06 (work in progress), December 2002. McDonald, et al. Expires July 24, 2003 [Page 15] Internet-Draft NTLP Design Considerations January 2003 [3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984. [4] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [5] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [7] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [8] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [9] Braden, R. and B. Lindell, "A Two-Level Architecture for Internet Signaling", draft-braden-2level-signal-arch-01 (work in progress), November 2002. [10] Hancock, R., "Sender and Receiver Orientation Issues in NSIS", draft-hancock-nsis-sender-receiver-00 (work in progress), October 2002. [11] Schulzrinne, H., "CASP - Cross-Application Signaling Protocol", draft-schulzrinne-nsis-casp-00 (work in progress), September 2002. [12] Westberg, L., "Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205", draft-westberg-nsis-rsvp-as-ntlp-00 (work in progress), January 2003. [13] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft-thomas-nsis-rsvp-analysis-00 (work in progress), November 2002. [14] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", draft-ietf-aaa-transport-12 (work in progress), January 2003. [15] McDonald, et al. Expires July 24, 2003 [Page 16] Internet-Draft NTLP Design Considerations January 2003 Authors' Addresses Andrew McDonald Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN United Kingdom EMail: andrew.mcdonald@roke.co.uk Robert Hancock Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN United Kingdom EMail: robert.hancock@roke.co.uk Eleanor Hepworth Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN United Kingdom EMail: eleanor.hepworth@roke.co.uk McDonald, et al. Expires July 24, 2003 [Page 17] Internet-Draft NTLP Design Considerations January 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. McDonald, et al. Expires July 24, 2003 [Page 18]