Requirements for Signaling Protocols
RFC 3726
| Document | Type |
RFC
- Informational
(April 2004)
Was
draft-ietf-nsis-req
(nsis WG)
|
|
|---|---|---|---|
| Author | Marcus Brunner | ||
| Last updated | 2013-03-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Allison J. Mankin | |
| Send notices to | (None) |
RFC 3726
5.7.4. Replay Protection To prevent replay of previous signaling messages the signaling protocol MUST provide means to detect old i.e., already transmitted signaling messages. A solution must cover issues of synchronization problems in the case of a restart or a crash of a participating network element. 5.7.5. Hop-by-Hop Security Channel security between signaling entities MUST be implemented. It is a well known and proven concept in Quality of Service and other signaling protocols to have intermediate nodes that actively participate in the protocol to modify the messages as it is required by processing rules. Note that this requirement does not exclude end-to-end or network-to-network security of a signaling message. End-to-end security between the NSIS Initiator and the NSIS Responder may be used to provide protection of non-mutable data fields. Network-to-network security refers to the protection of messages over various hops but not in an end-to-end manner i.e., protected over a particular network. 5.7.6. Identity Confidentiality and Network Topology Hiding Identity confidentiality SHOULD be supported. It enables privacy and avoids profiling of entities by adversary eavesdropping the signaling traffic along the path. The identity used in the process of authentication may also be hidden to a limited extent from a network to which the initiator is attached. However the identity MUST provide enough information for the nodes in the access network to collect accounting data. Network topology hiding MAY be supported to prevent entities along the path to learn the topology of a network. Supporting this property might conflict with a diagnostic capability. 5.7.7. Denial-of-Service Attacks A signaling protocol SHOULD provide prevention of Denial-of-service attacks. To effectively prevent denial-of-service attacks it is necessary that the used security and protocol mechanisms MUST have low computational complexity to verify a state setup request prior to authenticating the requesting entity. Additionally the signaling protocol and the used security mechanisms SHOULD NOT require large resource consumption on NSIS Entities (for example main memory or other additional message exchanges) before a successful authentication is done. Brunner Informational [Page 21] RFC 3726 Requirements for Signaling Protocols April 2004 5.7.8. Confidentiality of Signaling Messages Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. Since the ability to listen to signaling channels is a major guide to what data channels are interesting ones. To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner SHOULD be provided. Note that most messages must be protected on a hop-by-hop basis, since entities, which actively participate in the signaling protocol, must be able to read and eventually modify the signaling messages. 5.7.9. Ownership of State When existing states have to be modified then there is a need to use a session identifier to uniquely identify the established state. A signaling protocol MUST provide means of security protection to prevent adversaries from modifying state. 5.8. Mobility 5.8.1. Allow Efficient Service Re-Establishment After Handover Handover is an essential function in wireless networks. After handover, the states may need to be completely or partially re- established due to route changes. The re-establishment may be requested by the mobile node itself or triggered by the access point that the mobile node is attached to. In the first case, the signaling MUST allow efficient re-establishment after handover. Re- establishment after handover MUST be as quick as possible so that the mobile node does not experience service interruption or service degradation. The re-establishment SHOULD be localized, and not require end-to-end signaling. 5.9. Interworking with Other Protocols and Techniques Hooks SHOULD be provided to enable efficient interworking between various protocols and techniques including the following listed. 5.9.1. MUST Interwork with IP Tunneling IP tunneling for various applications MUST be supported. More specifically IPSec tunnels are of importance. This mainly impacts the identification of flows. When using IPSec, parts of information commonly used for flow identification (e.g., transport protocol information and ports) may not be accessible due to encryption. Brunner Informational [Page 22] RFC 3726 Requirements for Signaling Protocols April 2004 5.9.2. MUST NOT Constrain Either to IPv4 or IPv6 5.9.3. MUST be Independent from Charging Model Signaling MUST NOT be constrained by charging models or the charging infrastructure used. 5.9.4. SHOULD Provide Hooks for AAA Protocols The NSIS protocol SHOULD be developed with respect to be able to collect usage records from one or more network elements. 5.9.5. SHOULD Work with Seamless Handoff Protocols An NSIS protocol SHOULD work with seamless handoff protocols such as context transfer and candidate access router (CAR) discovery. 5.9.6. MUST Work with Traditional Routing NSIS assumes traditional L3 routing, which is purely based on L3 destination addresses. NSIS MUST work with L3 routing, in particular it MUST work in case of route changes. This means state on the old route MUST be released and state on the new route MUST be established by an NSIS protocol. Networks, which do non-traditional routing, should not break NSIS signaling. NSIS MAY work for some of these situations. Particularly, combinations of NSIS unaware nodes and routing other then traditional one causes some problems. Non-traditional routing includes, for example, routing decisions based on port numbers, other IP header fields than the destination address, or splitting traffic based on header hash values. These routing environments result in the signaling path being potentially different than the data path. 5.10. Operational 5.10.1. Ability to Assign Transport Quality to Signaling Messages The NSIS architecture SHOULD allow the network operator to assign the NSIS protocol messages a certain transport quality. As signaling opens up the possibility of denial-of-service attacks, this requirement gives the network operator a means, but also the obligation, to trade-off between signaling latency and the impact (from the signaling messages) on devices within the network. From protocol design this requirement states that the protocol messages SHOULD be detectable, at least where the control and assignment of the messages priority is done. Brunner Informational [Page 23] RFC 3726 Requirements for Signaling Protocols April 2004 Furthermore, the protocol design must take into account reliability concerns. Communication reliability is seen as part of the quality assigned to signaling messages. So procedures MUST be defined for how an NSIS signaling system behaves if some kind of request it sent stays unanswered. The basic transport protocol to be used between adjacent NSIS Entities MAY ensure message integrity and reliable transport. 5.10.2. Graceful Fail Over Any unit participating in NSIS signaling MUST NOT cause further damage to other systems involved in NSIS signaling when it has to go out of service. 5.10.3. Graceful Handling of NSIS Entity Problems NSIS entities SHOULD be able to detect a malfunctioning peer. It may notify the NSIS Initiator or another NSIS entity involved in the signaling process. The NSIS peer may handle the problem itself e.g., switching to a backup NSIS entity. In the latter case note that synchronization of state between the primary and the backup entity is needed. 6. Security Considerations Section 5.7 of this document provides security related requirements of a signaling protocol. 7. Acknowledgments Quite a number of people have been involved in the discussion of the document, adding some ideas, requirements, etc. We list them without a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical University Berlin), Xiaoming Fu (Technical University Berlin), Hans- Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya Freytsis. Some text and/or ideas for text, requirements, scenarios have been taken from an Internet Draft written by the following authors: David Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have actively contributed new text to this document as well. Brunner Informational [Page 24] RFC 3726 Requirements for Signaling Protocols April 2004 Another Internet Draft impacting this document has been written by Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel). These people contributed also new text. Thanks also to Kwok Ho Chan (Nortel) for text changes. And finally thanks Alison Mankin for the thorough AD review and thanks to Harald Tveit Alvestrand and Steve Bellovin for the IESG review comments. Brunner Informational [Page 25] RFC 3726 Requirements for Signaling Protocols April 2004 8. Appendix: Scenarios/Use Cases In the following we describe scenarios, which are important to cover, and which allow us to discuss various requirements. Some regard this as use cases to be covered defining the use of a signaling protocol. In general, these scenarios consider the specific case of signaling for QoS (resource reservation), although many of the issues carry over directly to other signaling types. 8.1. Terminal Mobility The scenario we are looking at is the case where a mobile terminal (MT) changes from one access point to another access point. The access points are located in separate QoS domains. We assume Mobile IP to handle mobility on the network layer in this scenario and consider the various extensions (i.e., IETF proposals) to Mobile IP, in order to provide 'fast handover' for roaming Mobile Terminals. The goal to be achieved lies in providing, keeping, and adapting the requested QoS for the ongoing IP sessions in case of handover. Furthermore, the negotiation of QoS parameters with the new domain via the old connection might be needed, in order to support the different 'fast handover' proposals within the IETF. The entities involved in this scenario include a mobile terminal, access points, an access network manager, and communication partners of the MT (the other end(s) of the communication association). From a technical point of view, terminal mobility means changing the access point of a mobile terminal (MT). However, technologies might change in various directions (access technology, QoS technology, administrative domain). If the access points are within one specific QoS technology (independent of access technology) we call this intra-QoS technology handoff. In the case of an inter-QoS technology handoff, one changes from e.g., a DiffServ to an IntServ domain, however still using the same access technology. Finally, if the access points are using different access technologies we call it inter-technology hand-off. The following issues are of special importance in this scenario: 1) Handoff decision - The QoS management requests handoff. The QoS management can decide to change the access point, since the traffic conditions of the new access point are better supporting the QoS requirements. The metric may be different (optimized towards a single or a group/class of users). Note that the MT or the network (see below) might trigger the handoff. Brunner Informational [Page 26] RFC 3726 Requirements for Signaling Protocols April 2004 - The mobility management forces handoff. This can have several reasons. The operator optimizes his network, admission is no longer granted (e.g., emptied prepaid condition). Or another example is when the MT is reaching the focus of another base station. However, this might be detected via measurements of QoS on the physical layer and is therefore out of scope of QoS signaling in IP. Note again that the MT or the network (see below) might trigger the handoff. - This scenario shows that local decisions might not be enough. The rest of the path to the other end of the communication needs to be considered as well. Hand-off decisions in a QoS domain do not only depend on the local resource availability, e.g., the wireless part, but involve the rest of the path as well. Additionally, decomposition of an end-to-end signaling might be needed, in order to change only parts of it. 2) Trigger sources - Mobile terminal: If the end-system QoS management identifies another (better-suited) access point, it will request the handoff from the terminal itself. This will be especially likely in the case that two different provider networks are involved. Another important example is when the current access point bearer disappears (e.g., removing the Ethernet cable). In this case, the NSIS Initiator is basically located on the mobile terminal. - Network (access network manager): Sometimes, the handoff trigger will be issued from the network management to optimize the overall load situation. Most likely this will result in changing the base-station of a single providers network. Most likely the NSIS Initiator is located on a system within the network. 3) Integration with other protocols - Interworking with other protocol must be considered in one or the other form. E.g., it might be worth combining QoS signaling between different QoS domains with mobility signaling at hand- over. 4) Handover rates In mobile networks, the admission control process has to cope with far more admission requests than call setups alone would generate. For example, in the GSM (Global System for Mobile communications) case, mobility usually generates an average of one to two handovers Brunner Informational [Page 27] RFC 3726 Requirements for Signaling Protocols April 2004 per call. For third generation networks (such as UMTS), where it is necessary to keep radio links to several cells simultaneously (macro-diversity), the handover rate is significantly higher. 5) Fast state installation Handover can also cause packet losses. This happens when the processing of an admission request causes a delayed handover to the new base station. In this situation, some packets might be discarded, and the overall speech quality might be degraded significantly. Moreover, a delay in handover may cause degradation for other users. In the worst-case scenario, a delay in handover may cause the connection to be dropped if the handover occurred due to bad air link quality. Therefore, it is critical that QoS signaling in connection with handover be carried out very quickly. 6) Call blocking in case of overload Furthermore, when the network is overloaded, it is preferable to keep states for previously established flows while blocking new requests. Therefore, the resource reservation requests in connection with handover should be given higher priority than new requests for resource reservation. 8.2. Wireless Networks In this scenario, the user is using the packet services of a wireless system (such as the 3rd generation wireless system 3GPP/UMTS, 3GPP2/cdma2000). The region between the End Host and the Edge Node (Edge Router) connecting the wireless network to another QoS domain is considered to be a single QoS domain. The issues in such an environment regarding QoS include: 1) The wireless networks provide their own QoS technology with specialized parameters to coordinate the QoS provided by both the radio access and wired access networks. Provisioning of QoS technologies within a wireless network can be described mainly in terms of calling bearer classes, service options, and service instances. These QoS technologies need to be invoked with suitable parameters when higher layers trigger a request for QoS. Therefore these involve mapping of the requested higher layer QoS parameters onto specific bearer classes or service instances. The request for allocation of resources might be triggered by signaling at the IP level that passes across the wireless system, and possibly other QoS domains. Typically, wireless network specific messages are invoked to setup the underlying bearer Brunner Informational [Page 28] RFC 3726 Requirements for Signaling Protocols April 2004 classes or service instances in parallel with the IP layer QoS negotiation, to allocate resources within the radio access network. 2) The IP signaling messages are initiated by the NSIS initiator and interpreted by the NSIS Forwarder. The most efficient placement of the NSIS Initiator and NSIS Forwarder has not been determined in wireless networks, but a few potential scenarios can be envisioned. The NSIS Initiator could be located at the End Host (e.g., 3G User equipment (UE)), the Access Gateway or at a node that is not directly on the data path, such as a Policy Decision Function. The Access Gateway could act as a proxy NSIS Initiator on behalf of the End Host. The Policy Decision Function that controls per-flow/aggregate resources with respect to the session within its QoS domain (e.g., the 3G wireless network) may act as a proxy NSIS Initiator for the end host or the Access Gateway. Depending on the placement of the NSIS Initiator, the NSIS Forwarder may be located at an appropriate point in the wireless network. 3) The need for re-negotiation of resources in a new wireless domain due to host mobility. In this case the NSIS Initiator and the NSIS Forwarder should detect mobility events and autonomously trigger re-negotiation of resources. 8.3. An Example Scenario for 3G Wireless Networks The following example is a pure hypothetical scenario, where an NSIS signaling protocol might be used in a 3G environment. We do not impose in any way, how a potential integration might be done. Terms from the 3GPP architecture are used (P-CSCF, IMS, expanded below) in order to give specificity, but in a hypothetical design, one that reflects neither development nor review by 3GPP. The example should help in the design of a NSIS signaling protocol such that it could be used in various environments. The 3G wireless access scenario is shown in Figure 1. The Proxy-Call State Control Function (P-CSCF) is the outbound SIP proxy (only used in IP Multimedia Subsystems (IMS)). The Access Gateway is the egress router of the 3G wireless domain and it connects the radio access network to the Edge Router (ER) of the backbone IP network. The Policy Decision Function (PDF) is an entity responsible for controlling bearer level resource allocations/de-allocations in relation to session level services e.g., SIP. The Policy Decision Function may also control the Access Gateway to open and close the gates and to configure per-flow policies, i.e., to authorize or forbid user traffic. The P-CSCF (only used in IMS) and the Access Gateway communicate with the Policy Decision Function, for network Brunner Informational [Page 29] RFC 3726 Requirements for Signaling Protocols April 2004 resource allocation/de-allocation decisions. The User Equipment (UE) or the Mobile Station (MS) consists of a Mobile Terminal (MT) and Terminal Equipment (TE), e.g., a laptop. +--------+ +--------->| P-CSCF |---------> SIP signaling / +--------+ / SIP | | | | +-----+ +----------------+ | | PDF |<---------->| NSIS Forwarder |<---> | +-----+ +----------------+ | | ^ | | | | | | | |COPS | | | | +------+ +---------+ | | UE/MS|----------| Access |<-----------+ +----+ +------+ | Gateway |------------------| ER | +---------+ +----+ Figure 1: 3G wireless access scenario The PDF has all the required QoS information for per-flow or aggregate admission control in 3G wireless networks. It receives resource allocation/de-allocation requests from the P-CSCF and/or Access Gateway etc. and responds with policy decisions. Hence the PDF may be a candidate entity to host the functionality of the NSIS Initiator, initiating the NSIS QoS signaling towards the backbone IP network. On the other hand, the UE/MS may act as the NSIS Initiator or the Access Gateway may act as a Proxy NSIS Initiator on behalf of the UE/MS. In the former case, the P-CSCF/PDF has to do the mapping from codec types and media descriptors (derived from SIP/SDP signaling) to IP traffic descriptor. In the latter case, the UE/MS may use any appropriate QoS signaling mechanism as the NSIS Initiator. If the Access Gateway is acting as the Proxy NSIS initiator on behalf of the UE/MS, then it may have to do the mapping of parameters from radio access specific QoS to IP QoS traffic parameters before forwarding the request to the NSIS Forwarder. The NSIS Forwarder is currently not part of the standard 3G wireless architecture. However, to achieve end-to-end QoS a NSIS Forwarder is needed such that the NSIS Initiators can request a QoS connection to the IP network. As in the previous example, the NSIS Forwarder could manage a set of pre-provisioned resources in the IP network, i.e., bandwidth pipes, and the NSIS Forwarder perform per-flow admission control into these pipes. In this way, a connection can be made Brunner Informational [Page 30] RFC 3726 Requirements for Signaling Protocols April 2004 between two 3G wireless access networks, and hence, end-to-end QoS can be achieved. In this case the NSIS Initiator and NSIS Forwarder are clearly two separate logical entities. The Access Gateway or/and the Edge Router in Fig.1 may contain the NSIS Forwarder functionality, depending upon the placement of the NSIS Initiator as discussed in scenario 2 in section 8.2. This use case clearly illustrates the need for an NSIS QoS signaling protocol between NSIS Initiator and NSIS Forwarder. An important application of such a protocol may be its use in the end-to-end establishment of a connection with specific QoS characteristics between a mobile host and another party (e.g., end host or content server). 8.4. Wired Part of Wireless Network A wireless network, seen from a QoS domain perspective, usually consists of three parts: a wireless interface part (the "radio interface"), a wired part of the wireless network (i.e., Radio Access Network) and the backbone of the wireless network, as shown in Figure 2. Note that this figure should not be seen as an architectural overview of wireless networks but rather as showing the conceptual QoS domains in a wireless network. In this scenario, a mobile host can roam and perform a handover procedure between base stations/access routers. In this scenario the NSIS QoS protocol can be applied between a base station and the gateway (GW). In this case a GW can also be considered as a local handover anchor point. Furthermore, in this scenario the NSIS QoS protocol can also be applied either between two GWs, or between two edge routers (ER). Brunner Informational [Page 31] RFC 3726 Requirements for Signaling Protocols April 2004 |--| |GW| |--| |--| |MH|--- . |--| / |-------| . /--|base | |--| . |station|-|ER|... |-------| |--| . |--| back- |--| |---| |----| ..|ER|.......|ER|..|BGW|.."Internet"..|host| -- |-------| |--| . |--| bone |--| |---| |----| |--| \ |base |-|ER|... . |MH| \ |station| |--| . |--|--- |-------| . MH = mobile host |--| ER = edge router <----> |GW| GW = gateway Wireless link |--| BGW = border gateway ... = interior nodes <-------------------> Wired part of wireless network <----------------------------------------> Wireless Network Figure 2. QoS architecture of wired part of wireless network Each of these parts of the wireless network impose different issues to be solved on the QoS signaling solution being used: 1) Wireless interface: The solution for the air interface link has to ensure flexibility and spectrum efficient transmission of IP packets. However, this link layer QoS can be solved in the same way as any other last hop problem by allowing a host to request the proper QoS profile. 2) Wired part of the wireless network: This is the part of the network that is closest to the base stations/access routers. It is an IP network although some parts logically perform tunneling of the end user data. In cellular networks, the wired part of the wireless network is denoted as a radio access network. This part of the wireless network has different requirements for signaling protocol characteristics when compared to traditional IP networks: - The network must support mobility. Many wireless networks are able to provide a combination of soft and hard handover procedures. When handover occurs, reservations need to be established on new paths. The establishment time has to be as Brunner Informational [Page 32] RFC 3726 Requirements for Signaling Protocols April 2004 short as possible since long establishment times for s degrade the performance of the wireless network. Moreover, for maximal utilization of the radio spectrum, frequent handover operations are required. - These links are typically rather bandwidth-limited. - The wired transmission in such a network contains a relatively high volume of expensive leased lines. Overprovisioning might therefore be prohibitively expensive. - The radio base stations are spread over a wide geographical area and are in general situated a large distance from the backbone. 3) Backbone of the wireless network: the requirements imposed by this network are similar to the requirements imposed by other types of backbone networks. Due to these very different characteristics and requirements, often contradictory, different QoS signaling solutions might be needed in each of the three network parts. 8.5. Session Mobility In this scenario, a session is moved from one end-system to another. Ongoing sessions are kept and QoS parameters need to be adapted, since it is very likely that the new device provides different capabilities. Note that it is open which entity initiates the move, which implies that the NSIS Initiator might be triggered by different entities. User mobility (i.e., a user changing the device and therefore moving the sessions to the new device) is considered to be a special case within the session mobility scenario. Note that this scenario is different from terminal mobility. The terminal (end-system) has not moved to a different access point. Both terminals are still connected to an IP network at their original points. The issues include: 1) Keeping the QoS guarantees negotiated implies that the end- point(s) of communication are changed without changing the s. 2) The trigger of the session move might be the user or any other party involved in the session. Brunner Informational [Page 33] RFC 3726 Requirements for Signaling Protocols April 2004 8.6. QoS Reservation/Negotiation from Access to Core Network The scenario includes the signaling between access networks and core networks in order to setup and change reservations together with potential negotiation. The issues to be solved in this scenario are different from previous ones. 1) The entity of reservation is most likely an aggregate. 2) The time scales of states might be different (long living states of aggregates, less often re-negotiation). 3) The specification of the traffic (amount of traffic), a particular QoS is guaranteed for, needs to be changed. E.g., in case additional flows are added to the aggregate, the traffic specification of the flow needs to be added if it is not already included in the aggregates specification. 4) The flow specification is more complex including network addresses and sets of different address for the source as well as for the destination of the flow. 8.7. QoS Reservation/Negotiation Over Administrative Boundaries Signaling between two or more core networks to provide QoS is handled in this scenario. This might also include access to core signaling over administrative boundaries. Compared to the previous one it adds the case, where the two networks are not in the same administrative domain. Basically, it is the inter-domain/inter-provider signaling which is handled in here. The domain boundary is the critical issue to be resolved. Which of various flavors of issues a QoS signaling protocol has to be concerned with. 1) Competing administrations: Normally, only basic information should be exchanged, if the signaling is between competing administrations. Specifically information about core network internals (e.g., topology, technology, etc.) should not be exchanged. Some information exchange about the "access points" of the core networks (which is topology information as well) may be required, to be exchanged, because it is needed for proper signaling. 2) Additionally, as in scenario 4, signaling most likely is based on aggregates, with all the issues raise there. Brunner Informational [Page 34] RFC 3726 Requirements for Signaling Protocols April 2004 3) Authorization: It is critical that the NSIS Initiator is authorized to perform a QoS path setup. 4) Accountability: It is important to notice that signaling might be used as an entity to charge money for, therefore the interoperation with accounting needs to be available. 8.8. QoS Signaling Between PSTN Gateways and Backbone Routers A PSTN gateway (i.e., host) requires information from the network regarding its ability to transport voice traffic across the network. The voice quality will suffer due to packet loss, latency and jitter. Signaling is used to identify and admit a flow for which these impairments are minimized. In addition, the disposition of the signaling request is used to allow the PSTN GW to make a call routing decision before the call is actually accepted and delivered to the final destination. PSTN gateways may handle thousands of calls simultaneously and there may be hundreds of PSTN gateways in a single provider network. These numbers are likely to increase as the size of the network increases. The point being that scalability is a major issue. There are several ways that a PSTN gateway can acquire assurances that a network can carry its traffic across the network. These include: 1. Over-provisioning a high availability network. 2. Handling admission control through some policy server that has a global view of the network and its resources. 3. Per PSTN GW pair admission control. 4. Per call admission control (where a call is defined as the 5-tuple used to carry a single RTP flow). Item 1 requires no signaling at all and is therefore outside the scope of this working group. Item 2 is really a better informed version of 1, but it is also outside the scope of this working group as it relies on a particular telephony signaling protocol rather than a packet admission control protocol. Item 3 is initially attractive, as it appears to have reasonable scaling properties, however, its scaling properties only are effective in cases where there are relatively few PSTN GWs. In the Brunner Informational [Page 35] RFC 3726 Requirements for Signaling Protocols April 2004 more general case where a PSTN GW reduces to a single IP phone sitting behind some access network, the opportunities for aggregation are reduced and the problem reduces to item 4. Item 4 is the most general case. However, it has the most difficult scaling problems. The objective here is to place the requirements on Item 4 such that a scalable per-flow admission control protocol or protocol suite may be developed. The case where per-flow signaling extends to individual IP end-points allows the inclusion of IP phones on cable, DSL, wireless or other access networks in this scenario. Call Scenario A PSTN GW signals end-to-end for some 5-tuple defined flow a bandwidth and QoS requirement. Note that the 5-tuple might include masking/wildcarding. The access network admits this flow according to its local policy and the specific details of the access technology. At the edge router (i.e., border node), the flow is admitted, again with an optional authentication process, possibly involving an external policy server. Note that the relationship between the PSTN GW and the policy server and the routers and the policy server is outside the scope of NSIS. The edge router then admits the flow into the core of the network, possibly using some aggregation technique. At the interior nodes, the NSIS host-to-host signaling should either be ignored or invisible as the Edge router performed the admission control decision to some aggregate. At the inter-provider router (i.e., border node), again the NSIS host-to-host signaling should either be ignored or invisible, as the Edge router has performed an admission control decision about an aggregate across a carrier network. 8.9. PSTN Trunking Gateway One of the use cases for the NSIS signaling protocol is the scenario of interconnecting PSTN gateways with an IP network that supports QoS. Brunner Informational [Page 36] RFC 3726 Requirements for Signaling Protocols April 2004 Four different scenarios are considered here. 1. In-band QoS signaling is used. In this case the Media Gateway (MG) will be acting as the NSIS Initiator and the Edge Router (ER) will be the NSIS Forwarder. Hence, the ER should do admission control (into pre-provisioned traffic trunks) for the individual traffic flows. This scenario is not further considered here. 2. Out-of-band signaling in a single domain, the NSIS forwarder is integrated in the Media Gateway Controller (MGC). In this case no NSIS protocol is required. 3. Out-of-band signaling in a single domain, the NSIS forwarder is a separate box. In this case NSIS signaling is used between the MGC and the NSIS Forwarder. 4. Out-of-band signaling between multiple domains, the NSIS Forwarder (which may be integrated in the MGC) triggers the NSIS Forwarder of the next domain. When the out-of-band QoS signaling is used the Media Gateway Controller (MGC) will be acting as the NSIS Initiator. In the second scenario the voice provider manages a set of traffic trunks that are leased from a network provider. The MGC does the admission control in this case. Since the NSIS Forwarder acts both as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is required. This scenario is shown in Figure 3. +-------------+ ISUP/SIGTRAN +-----+ +-----+ | SS7 network |---------------------| MGC |--------------| SS7 | +-------------+ +-------+-----+---------+ +-----+ : / : \ : / : \ : / +--------:----------+ \ : MEGACO / / : \ \ : / / +-----+ \ \ : / / | NMS | \ \ : / | +-----+ | \ : : | | : +--------------+ +----+ | bandwidth pipe (SLS) | +----+ | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- +--------------+ +----+ \ / +----+ \ QoS network / +-------------------+ Figure 3: PSTN trunking gateway scenario Brunner Informational [Page 37] RFC 3726 Requirements for Signaling Protocols April 2004 In the third scenario, the voice provider does not lease traffic trunks in the network. Another entity may lease traffic trunks and may use a NSIS Forwarder to do per-flow admission control. In this case the NSIS signaling is used between the MGC and the NSIS Forwarder, which is a separate box here. Hence, the MGC acts only as a NSIS Initiator. This scenario is depicted in Figure 4. +-------------+ ISUP/SIGTRAN +-----+ +-----+ | SS7 network |---------------------| MGC |--------------| SS7 | +-------------+ +-------+-----+---------+ +-----+ : / : \ : / +-----+ \ : / | NF | \ : / +-----+ \ : / : \ : / +--------:----------+ \ : MEGACO : / : \ : : : / +-----+ \ : : : / | NMS | \ : : : | +-----+ | : : : | | : +--------------+ +----+ | bandwidth pipe (SLS) | +----+ | PSTN network |--| MG |--|ER|======================|ER|-| MG |-- +--------------+ +----+ \ / +----+ \ QoS network / +-------------------+ Figure 4: PSTN trunking gateway scenario In the fourth scenario multiple transport domains are involved. In the originating network either the MGC may have an overview on the resources of the overlay network or a separate NSIS Forwarder will have the overview. Hence, depending on this either the MGC or the NSIS Forwarder of the originating domain will contact the NSIS Forwarder of the next domain. The MGC always acts as a NSIS Initiator and may also be acting as a NSIS Forwarder in the first domain. 8.10. An Application Requests End-to-End QoS Path from the Network This is actually the conceptually simplest case. A multimedia application requests a guaranteed service from an IP network. We assume here that the application is somehow able to specify the network service. The characteristics here are that many hosts might do it, but that the requested service is low capacity (bounded by the access line). Note that there is an issue of scaling in the number of applications requesting this service in the core of the network. Brunner Informational [Page 38] RFC 3726 Requirements for Signaling Protocols April 2004 8.11. QOS for Virtual Private Networks In a Virtual Private Network (VPN), a variety of tunnels might be used between its edges. These tunnels could be for example, IPSec, GRE, and IP-IP. One of the most significant issues in VPNs is related to how a flow is identified and what quality a flow gets. A flow identification might consist among others of the transport protocol port numbers. In an IP-Sec tunnel this will be problematic since the transport protocol information is encrypted. There are two types of L3 VPNs, distinguished by where the endpoints of the tunnels exist. The endpoints of the tunnels may either be on the customer (CPE) or the provider equipment or provider edge (PE). Virtual Private networks are also likely to request bandwidth or other type of service in addition to the premium services the PSTN GW are likely to use. 8.11.1. Tunnel End Points at the Customer Premises When the endpoints are the CPE, the CPE may want to signal across the public IP network for a particular amount of bandwidth and QoS for the tunnel aggregate. Such signaling may be useful when a customer wants to vary their network cost with demand, rather than paying a flat rate. Such signaling exists between the two CPE routers. Intermediate access and edge routers perform the same exact call admission control, authentication and aggregation functions performed by the corresponding routers in the PSTN GW scenario with the exception that the endpoints are the CPE tunnel endpoints rather than PSTN GWs and the 5-tuple used to describe the RTP flow is replaced with the corresponding flow spec to uniquely identify the tunnels. Tunnels may be of any variety (e.g., IP-Sec, GRE, IP-IP). In such a scenario, NSIS would actually allow partly for customer managed VPNs, which means a customer can setup VPNs by subsequent NSIS signaling to various end-point. Plus the tunnel end-points are not necessarily bound to an application. The customer administrator might be the one triggering NSIS signaling. 8.11.2. Tunnel End Points at the Provider Premises In the case were the tunnel end-points exist on the provider edge, requests for bandwidth may be signaled either per flow, where a flow is defined from a customers address space, or between customer sites. In the case of per flow signaling, the PE router must map the bandwidth request to the tunnel carrying traffic to the destination specified in the flow spec. Such a tunnel is a member of an Brunner Informational [Page 39] RFC 3726 Requirements for Signaling Protocols April 2004 aggregate to which the flow must be admitted. In this case, the operation of admission control is very similar to the case of the PSTN GW with the additional level of indirection imposed by the VPN tunnel. Therefore, authentication, accounting and policing may be required on the PE router. In the case of per site signaling, a site would need to be identified. This may be accomplished by specifying the network serviced at that site through an IP prefix. In this case, the admission control function is performed on the aggregate to the PE router connected to the site in question. 9. References 9.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. Brunner Informational [Page 40] RFC 3726 Requirements for Signaling Protocols April 2004 10. Authors' Addresses Marcus Brunner (Editor) NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 D-69115 Heidelberg Germany EMail: brunner@netlab.nec.de Robert Hancock Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom EMail: robert.hancock@roke.co.uk Eleanor Hepworth Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom EMail: eleanor.hepworth@roke.co.uk Cornelia Kappler Siemens AG Berlin 13623 Germany EMail: cornelia.kappler@siemens.com Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munchen Germany EMail: Hannes.Tschofenig@mchp.siemens.de Brunner Informational [Page 41] RFC 3726 Requirements for Signaling Protocols April 2004 11. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Brunner Informational [Page 42]