Signalling Connection Control Part User Adaptation Layer (SUA)
RFC 3868
Document | Type | RFC - Proposed Standard (October 2004) IPR | |
---|---|---|---|
Authors | Gery Verwimp, Brian Bidulock , Joe Keller , Greg Sidebottom , Lode Coene , John A. Loughney | ||
Last updated | 2015-10-14 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | Jon Peterson | |
Send notices to | (None) |
RFC 3868
Network Working Group A. Atlas Internet-Draft Juniper Networks Intended status: Informational J. Halpern Expires: December 25, 2014 Ericsson S. Hares Hickory Hill Consulting D. Ward Cisco Systems T. Nadeau Brocade June 23, 2014 An Architecture for the Interface to the Routing System draft-ietf-i2rs-architecture-04 Abstract This document describes an architecture for a standard, programmatic interface for state transfer in and out of the internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of I2RS. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 25, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Atlas, et al. Expires December 25, 2014 [Page 1] Internet-Draft I2RS Arch June 2014 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Key Architectural Properties . . . . . . . . . . . . . . . . 10 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4.1. Identity and Authentication . . . . . . . . . . . . . . . 13 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 5. Network Applications and I2RS Client . . . . . . . . . . . . 14 5.1. Example Network Application: Topology Manager . . . . . . 15 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15 6.1. Relationship to its Routing Element . . . . . . . . . . . 15 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17 6.3. Interactions with Local Config . . . . . . . . . . . . . 17 6.4. Routing Components and Associated I2RS Services . . . . . 18 6.4.1. Routing and Label Information Bases . . . . . . . . . 19 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21 6.4.5. Information Modeling, Device Variation, and Information Relationships . . . . . . . . . . . . . . 21 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance . . . . . . . . . . . . . . . . . . . 21 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22 6.4.5.3. Managing Variation: Templating . . . . . . . . . 22 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 23 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 23 6.4.5.4.2. Correlation Identification . . . . . . . . . 23 6.4.5.4.3. Object References . . . . . . . . . . . . . . 24 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 24 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 24 7.1. One Control and Data Exchange Protocol . . . . . . . . . 24 Atlas, et al. Expires December 25, 2014 [Page 2] Internet-Draft I2RS Arch June 2014quot;) MAY be sent to all inactive ASPs, if required. An ASP Inactive Ack message is sent to the ASP after all traffic is halted and Layer Management is informed with an M-ASP_INACTIVE indication primitive. Multiple ASP Inactive Ack messages MAY be used in response to an ASP Inactive message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge for different (sets of) Routing Contexts. The SGP or IPSP sends an Error message ("Invalid Routing Context") message for each invalid or not configured Routing Context value in a received ASP Inactive message. The SGP MUST send an ASP Inactive Ack message in response to a received ASP Inactive message from the ASP and the ASP is already marked as ASP-INACTIVE at the SGP. At the ASP, the ASP Inactive Ack message received is not acknowledged. Layer Management is informed with an M-ASP_INACTIVE confirm primitive. If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive message, the ASP should now consider itself as in the ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE state, the ASP should then initiate procedures to return itself to its previous state. When the ASP sends an ASP Inactive message it starts timer T(ack). If the ASP does not receive a response to an ASP Inactive message within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages until it receives an ASP Inactive Ack message. T(ack) is provisioned, with a default of 2 seconds. Alternatively, retransmission of ASP Inactive messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in a M-ASP_Inactive confirm primitive carrying a negative indication. Loughney, et al. Standards Track [Page 107] RFC 3868 SUA October 2004 If no other ASPs in the Application Server are in the state ASP- ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to all of the ASPs in the AS which are in the state ASP-INACTIVE. The SGP SHOULD start buffering the incoming messages for T(r) seconds, after which messages MAY be discarded. T(r) is configurable by the network operator. If the SGP receives an ASP Active message from an ASP in the AS before expiry of T(r), the buffered traffic is directed to that ASP and the timer is cancelled. If T(r) expires, the AS is moved to the AS-INACTIVE state. 4.3.4.4.1. IPSP Considerations An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive or ASP Inactive Ack message has been received from it. Alternatively, when using IPSP DE model, an interchange of ASP Inactive messages from each end MUST be performed. Four messages are needed for completion. 4.3.4.5. Notify Procedures A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change was a result of an ASP failure or reception of an ASP State management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any ASP State or Traffic Management related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). In the case where a Notify ("AS-PENDING") message is sent by an SGP that now has no ASPs active to service the traffic, or where a Notify ("Insufficient ASP resources active in AS") message MUST be sent in the Loadshare or Broadcast mode, the Notify message does not explicitly compel the ASP(s) receiving the message to become active. The ASPs remain in control of what (and when) traffic action is taken. In the case where a Notify message does not contain a Routing Context parameter, the receiver must know, via configuration data, of which Application Servers the ASP is a member and take the appropriate action in each AS. Loughney, et al. Standards Track [Page 108] RFC 3868 SUA October 2004 4.3.4.5.1. IPSP Considerations (NTFY) Notify works in the same manner as in the SG-AS case. One of the IPSPs can send this message to any remote IPSP that is not in the ASP-DOWN state. 4.3.4.6. Heartbeat Procedures The optional Heartbeat procedures MAY be used when operating over transport layers that do not have their own heartbeat mechanism for detecting loss of the transport association (i.e., other than SCTP). Either SUA peer may optionally send Heartbeat messages periodically, subject to a provisioned timer T(beat). Upon receiving a Heartbeat message, the SUA peer MUST respond with a Heartbeat Ack message. If no Heartbeat Ack message (or any other SUA message) is received from the SUA peer within 2*T(beat), the remote SUA peer is considered unavailable. Transmission of Heartbeat messages is stopped and the signalling process SHOULD attempt to reestablish communication if it is configured as the client for the disconnected SUA peer. The Heartbeat message may optionally contain an opaque Heartbeat Data parameter that MUST be echoed back unchanged in the related Heartbeat Ack message. The sender, upon examining the contents of the returned Heartbeat Ack message, MAY choose to consider the remote SUA peer as unavailable. The contents/format of the Heartbeat Data parameter is implementation-dependent and only of local interest to the original sender. The contents may be used, for example, to support a Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a timestamp mechanism (to evaluate delays). Note: Heartbeat related events are not shown in Figure 2 "ASP state transition diagram". 4.4. Routing Key Management Procedures 4.4.1. Registration An ASP MAY dynamically register with an SGP as an ASP within an Application Server using the REG REQ message. A Routing Key parameter in the REG REQ message specifies the parameters associated with the Routing Key. The SGP examines the contents of the received Routing Key parameter and compares it with the currently provisioned Routing Keys. If the received Routing Key matches an existing SGP Routing Key entry, and the ASP is not currently included in the list of ASPs for the related Loughney, et al. Standards Track [Page 109] RFC 3868 SUA October 2004 Application Server, the SGP MAY authorize the ASP to be added to the AS. Or, if the Routing Key does not currently exist and the received Routing Key data is valid and unique, an SGP supporting dynamic configuration MAY authorize the creation of a new Routing Key and related Application Server and add the ASP to the new AS. In either case, the SGP returns a Registration Response message to the ASP, containing the same Local-RK-Identifier as provided in the initial request, and a Registration Result "Successfully Registered". A unique Routing Context value assigned to the SGP Routing Key is included. The method of Routing Context value assignment at the SGP is implementation dependent but must be guaranteed to be unique for each Application Server or Routing Key supported by the SGP. If the SGP determines that the received Routing Key data is invalid, or contains invalid parameter values, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Invalid Routing Key", "Error - Invalid DPC", "Error - Invalid Network Appearance" as appropriate. If the SGP does not support the registration procedure, the SGP returns an Error message to the ASP, with an error code of "Unsupported Message Type". If the SGP determines that a unique Routing Key cannot be created, the SGP returns a Registration Response message to the ASP, with a Registration Status of "Error - Cannot Support Unique Routing". An incoming signalling message received at an SGP should not match against more than one Routing Key. If the SGP does not authorize the registration request, the SGP returns a REG RSP message to the ASP containing the Registration Result "Error - Permission Denied". If an SGP determines that a received Routing Key does not currently exist and the SGP does not support dynamic configuration, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key not Currently Provisioned". If an SGP determines that a received Routing Key does not currently exist and the SGP supports dynamic configuration but does not have the capacity to add new Routing Key and Application Server entries, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Insufficient Resources". If an SGP determines that one or more of the Routing Key parameters are not supported for the purpose of creating new Routing Key entries, the SGP returns a Registration Response message to the ASP, Loughney, et al. Standards Track [Page 110] RFC 3868 SUA October 2004 containing a Registration Result "Error - Unsupported RK parameter field". This result MAY be used if, for example, the SGP does not support RK Address parameter. A Registration Response "Error - Unsupported Traffic Handling Mode" is returned if the Routing Key in the REG REQ contains a Traffic Handling Mode that is inconsistent with the presently configured mode for the matching Application Server. An ASP MAY register multiple Routing Keys at once by including a number of Routing Key parameters in a single REG REQ message. The SGP MAY respond to each registration request in a single REG RSP message, indicating the success or failure result for each Routing Key in a separate Registration Result parameter. Alternatively the SGP MAY respond with multiple REG RSP messages, each with one or more Registration Result parameters. The ASP uses the Local-RK-Identifier parameter to correlate the requests with the responses. An ASP MAY modify an existing Routing Key by including a Routing Context parameter in the REG REQ. If the SGP determines that the Routing Context applies to an existing Routing Key, the SG MAY adjust the existing Routing Key to match the new information provided in the Routing Key parameter. A Registration Response "Routing Key Change Refused" is returned if the SGP does not accept the modification of the Routing Key. Upon successful registration of an ASP in an AS, the SGP can now send related SS7 Signalling Network Management messaging, if this did not previously start upon the ASP transitioning to state ASP-INACTIVE. 4.4.2. Deregistration An ASP MAY dynamically deregister with an SGP as an ASP within an Application Server using the DEREG REQ message. A Routing Context parameter in the DEREG REQ message specifies which Routing Keys to deregister. An ASP SHOULD move to the ASP-INACTIVE state for an Application Server before attempting to deregister the Routing Key (i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP SHOULD deregister from all Application Servers that it is a member before attempting to move to the ASP-Down state. The SGP examines the contents of the received Routing Context parameter and validates that the ASP is currently registered in the Application Server(s) related to the included Routing Context(s). If validated, the ASP is deregistered as an ASP in the related Application Server. Loughney, et al. Standards Track [Page 111] RFC 3868 SUA October 2004 The deregistration procedure does not necessarily imply the deletion of Routing Key and Application Server configuration data at the SGP. Other ASPs may continue to be associated with the Application Server, in which case the Routing Key data SHOULD NOT be deleted. If a Deregistration results in no more ASPs in an Application Server, an SGP MAY delete the Routing Key data. The SGP acknowledges the deregistration request by returning a DEREG RSP message to the requesting ASP. The result of the deregistration is found in the Deregistration Result parameter, indicating success or failure with cause. An ASP MAY deregister multiple Routing Contexts at once by including a number of Routing Contexts in a single DEREG REQ message. The SGP MAY respond to each deregistration request in a single DEREG RSP message, indicating the success or failure result for each Routing Context in a separate Deregistration Result parameter. 4.4.3. IPSP Considerations (REG/DEREG) The Registration/Deregistration procedures work in the IPSP cases in the same way as in AS-SG cases. An IPSP may register an RK in the remote IPSP. An IPSP is responsible for deregistering the RKs that it has registered. 4.5. Availability and/or Congestion Status of SS7 Destination Support 4.5.1. At an SGP On receiving a N-STATE, N-PCSTATE and N-INFORM indication primitive from the nodal interworking function at an SGP, the SGP SUA layer will send a corresponding SS7 Signalling Network Management (SNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the SUA peers at concerned ASPs. The SUA layer must fill in various fields of the SNM messages consistently with the information received in the primitives. The SGP SUA layer determines the set of concerned ASPs to be informed based on the specific SS7 network for which the primitive indication is relevant. In this way, all ASPs configured to send/receive traffic within a particular network appearance are informed. If the SGP operates within a single SS7 network appearance, then all ASPs are informed. DUNA, DAVA, SCON, and DRST messages are sent sequentially and processed at the receiver in the order sent. SCTP stream 0 SHOULD NOT be used. The Unordered bit in the SCTP DATA chunk MAY be used for the SCON message. Loughney, et al. Standards Track [Page 112] RFC 3868 SUA October 2004 Sequencing is not required for the DUPU or DAUD messages, which MAY be sent unordered. SCTP stream 0 is used, with optional use of the Unordered bit in the SCTP DATA chunk. 4.5.2. At an ASP 4.5.2.1. Single SG Configurations At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) message from the remote SUA Peer, the SUA layer invokes the appropriate primitive indications to the resident SUA-Users. Local management is informed. In the case where a local event has caused the unavailability or congestion status of SS7 destinations, the SUA layer at the ASP SHOULD pass up appropriate indications in the primitives to the SUA User, as though equivalent SSNM messages were received. For example, the loss of an SCTP association to an SGP may cause the unavailability of a set of SS7 destinations. N-PCSTATE indication primitives to the SUA User are appropriate. Implementation Note: To accomplish this, the SUA layer at an ASP maintains the status of routes via the SG. 4.5.2.2. Multiple SG Configurations At an ASP, upon receiving a Signalling Network Management message from the remote SUA Peer, the SUA layer updates the status of the affected route(s) via the originating SG and determines, whether or not the overall availability or congestion status of the effected destination(s) has changed. If so, the SUA layer invokes the appropriate primitive indications to the resident SUA-Users. Local management is informed. 4.5.3. ASP Auditing An ASP may optionally initiate an audit procedure to inquire of an SGP the availability and, if the national congestion method with multiple congestion levels and message priorities is used, congestion status of an SS7 destination or set of destinations. A Destination Audit (DAUD) message is sent from the ASP to the SGP requesting the current availability and congestion status of one or more SS7 destinations or subsystems. The DAUD message MAY be sent unordered. The ASP MAY send the DAUD in the following cases: Loughney, et al. Standards Track [Page 113] RFC 3868 SUA October 2004 - Periodic. A Timer originally set upon reception of a DUNA, SCON or DRST message has expired without a subsequent DAVA, DUNA, SCON or DRST message updating the availability/congestion status of the affected Destination Point Code. The Timer is reset upon issuing a DAUD. In this case the DAUD is sent to the SGP that originally sent the SSNM message. - Isolation. The ASP is newly ASP-ACTIVE or has been isolated from an SGP for an extended period. The ASP MAY request the availability/congestion status of one or more SS7 destinations to which it expects to communicate. Implementation Note: In the first of the cases above, the auditing procedure must not be invoked for the case of a received SCON message containing a congestion level value of "no congestion" or undefined" (i.e., congestion Level = "0"). This is because the value indicates either congestion abatement or that the ITU MTP3 international congestion method is being used. In the international congestion method, the MTP3 layer at the SGP does not maintain the congestion status of any destinations and therefore the SGP cannot provide any congestion information in response to the DAUD. For the same reason, in the second of the cases above a DAUD message cannot reveal any congested destination(s). The SGP SHOULD respond to a DAUD message with the availability and congestion status of the subsystem. The status of each SS7 destination or subsystem requested is indicated in a DUNA message (if unavailable), a DAVA message (if available), or a DRST (if restricted and the SGP supports this feature). If the SS7 destination or subsystem is available and congested, the SGP responds with an SCON message in addition to the DAVA message. If the SS7 destination or subsystem is restricted and congested, the SGP responds with an SCON message in addition to the DRST. If the SGP has no information on the availability / congestion status of the SS7 destination or subsystem, the SGP responds with a DUNA message, as it has no routing information to allow it to route traffic to this destination or subsystem. An SG MAY refuse to provide the availability or congestion status of a destination or subsystem if, for example, the ASP is not authorized to know the status of the destination or subsystem. The SG MAY respond with an Error Message (Error Code = "Destination Status Unknown") or Error Message (Error Code = "Subsystem Status Unknown"). Loughney, et al. Standards Track [Page 114] 7.2. Communication Channels . . . . . . . . . . . . . . . . . 24 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 25 7.4. Identity and Security Role . . . . . . . . . . . . . . . 25 7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 26 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 26 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27 7.7. Information collection . . . . . . . . . . . . . . . . . 27 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 28 8. Operational and Manageability Considerations . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 11. Informative References . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction Routers that form the internet routing infrastructure maintain state at various layers of detail and function. For example, a typical router maintains a Routing Information Base (RIB), and implements routing protocols such as OSPF, ISIS, and BGP to exchange protocol state and other information about the state of the network with other routers. Routers convert all of this information into forwarding entries which are then used to forward packets and flows between network elements. The forwarding plane and the specified forwarding entries then contain active state information that describes the expected and observed operational behavior of the router and which is also needed by the network applications. Network-oriented applications require easy access to this information to learn the network topology, to verify that programmed state is installed in the forwarding plane, to measure the behavior of various flows, routes or forwarding entries, as well as to understand the configured and active states of the router. This document sets out an architecture for a common, standards-based interface to this information. This Interface to the Routing System (I2RS) facilitates control and observation of the routing-related state (for example, a Routing Element RIB manager's state), as well as enabling network-oriented applications to be built on top of today's routed networks. The I2RS is a programmatic asynchronous interface for transferring state into and out of the internet routing system. This I2RS architecture recognizes that the routing system and a router's OS provide useful mechanisms that applications could harness to accomplish application-level goals. Atlas, et al. Expires December 25, 2014 [Page 3] Internet-Draft I2RS Arch June 2014 Fundamental to the I2RS are clear data models that define the semantics of the information that can be written and read. The I2RS provides a framework for registering for and requesting the appropriate information for each particular application. The I2RS provides a way for applications to customize network behavior while leveraging the existing routing system as desired. Although the I2RS architecture is general enough to support information and data models for a variety of data, and aspects of the I2RS solution may be useful in domain other than routing, I2RS and this document are specifically focused on an interface for routing data. 1.1. Drivers for the I2RS Architecture There are four key drivers that shape the I2RS architecture. First is the need for an interface that is programmatic, asynchronous, and offers fast, interactive access for atomic operations. Second is the access to structured information and state that is frequently not directly configurable or modeled in existing implementations or configuration protocols. Third is the ability to subscribe to structured, filterable event notifications from the router. Fourth, the operation of I2RS is to be data-model driven to facilitate extensibility and provide standard data-models to be used by network applications. I2RS is described as an asynchronous programmatic interface, the key properties of which are described in Section 5 of [I-D.ietf-i2rs-problem-statement]. The I2RS architecture facilitates obtaining information from the router. The I2RS architecture provides the ability to not only read specific information, but also to subscribe to targeted information streams and filtered and thresholded events. Such an interface also facilitates the injection of ephemeral state into the routing system. A non-routing protocol or application could inject state into a routing element via the state-insertion functionality of the I2RS and that state could then be distributed in a routing or signaling protocol and/or be used locally (e.g. to program the co-located forwarding plane). I2RS will only permit modification of state that would be safe, conceptually, to modify via local configuration; no direct manipulation of protocol-internal dynamically determined data is envisioned. Atlas, et al. Expires December 25, 2014 [Page 4] Internet-Draft I2RS Arch June 2014 1.2. Architectural Overview Figure 1 shows the basic architecture for I2RS between applications using I2RS, their associated I2RS Clients, and I2RS Agents. Applications access I2RS services through I2RS clients. A single client can provide access to one or more applications. In the figure, Clients A and B provide access to a single application, while Client P provides access to multiple applications. Applications can access I2RS services through local or remote clients. In the figure, Applicatons A and B access I2RS services through local clients, while Applications C, D and E access I2RS services through a remote client. The details of how applications communicate with a remote client is out of scope for I2RS. An I2RS Client can access one or more I2RS agents. In the figure, Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent can provide service to one or more clients. In the figure, I2RS Agent 1 provides services to Clients A, B and P while Agent 2 provides services to only Clients B and P. I2RS agents and clients communicate with one another using an asynchronous protocol. Therefore, a single client can post multiple simultaneous requests, either to a single agent or to multiple agents. Furthermore, an agent can process multiple requests, either from a single client or from multiple clients, simultaneously. The I2RS agent provides read and write access to selected data on the routing element that are organized into I2RS Services. Section 4 describes how access is mediated by authentication and access control mechanisms. In addition to read and write access, the I2RS agent allows clients to subscribe to different types of notifications about events affecting different object instances. An example not related to the creation, modification or deletion of an object instance is when a next-hop in the RIB is resolved enough to be used or when a particular route is selected by the RIB Manager for installation into the forwarding plane. Please see Section 7.6 and Section 7.7 for details. The scope of I2RS is to define the interactions between the I2RS agent and the I2RS client and the associated proper behavior of the I2RS agent and I2RS client. ****************** ***************** ***************** * Application C * * Application D * * Application E * ****************** ***************** ***************** ^ ^ ^ Atlas, et al. Expires December 25, 2014 [Page 5] Internet-Draft I2RS Arch June 2014 | | | |--------------| | |--------------| | | | v v v *************** * Client P * *************** ^ ^ | |-------------------------| *********************** | *********************** | * Application A * | * Application B * | * * | * * | * +----------------+ * | * +----------------+ * | * | Client A | * | * | Client B | * | * +----------------+ * | * +----------------+ * | ******* ^ ************* | ***** ^ ****** ^ ****** | | | | | | | |-------------| | | |-----| | | -----------------------| | | | | | | | ************ v * v * v ********* ***************** v * v ******** * +---------------------+ * * +---------------------+ * * | Agent 1 | * * | Agent 2 | * * +---------------------+ * * +---------------------+ * * ^ ^ ^ ^ * * ^ ^ ^ ^ * * | | | | * * | | | | * * v | | v * * v | | v * * +---------+ | | +--------+ * * +---------+ | | +--------+ * * | Routing | | | | Local | * * | Routing | | | | Local | * * | and | | | | Config | * * | and | | | | Config | * * |Signaling| | | +--------+ * * |Signaling| | | +--------+ * * +---------+ | | ^ * * +---------+ | | ^ * * ^ | | | * * ^ | | | * * | |----| | | * * | |----| | | * * v | v v * * v | v v * * +----------+ +------------+ * * +----------+ +------------+ * * | Dynamic | | Static | * * | Dynamic | | Static | * * | System | | System | * * | System | | System | * * | State | | State | * * | State | | State | * * +----------+ +------------+ * * +----------+ +------------+ * * * * * * Routing Element 1 * * Routing Element 2 * ******************************** ******************************** Figure 1: Architecture of I2RS clients and agents Atlas, et al. Expires December 25, 2014 [Page 6] Internet-Draft I2RS Arch June 2014 Routing Element: A Routing Element implements some subset of the routing system. It does not need to have a forwarding plane associated with it. Examples of Routing Elements can include: * A router with a forwarding plane and RIB Manager that runs ISIS, OSPF, BGP, PIM, etc., * A BGP speaker acting as a Route Reflector, * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a forwarding plane and associated RIB Manager, * A server that runs ISIS, OSPF, BGP and uses ForCES to control a remote forwarding plane, A Routing Element may be locally managed, whether via CLI, SNMP, or NETCONF. Routing and Signaling: This block represents that portion of the Routing Element that implements part of the internet routing system. It includes not merely standardized protocols (i.e. IS- IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager layer. Local Config: A Routing Element will provide the ability to configure and manage it. The Local Config may be provided via a combination of CLI, NETCONF, SNMP, etc. The black box behavior for interactions between the state that I2RS installs into the routing element and the Local Config must be defined. Dynamic System State: An I2RS agent needs access to state on a routing element beyond what is contained in the routing subsystem. Such state may include various counters, statistics, flow data, and local events. This is the subset of operational state that is needed by network applications based on I2RS that is not contained in the routing and signaling information. How this information is provided to the I2RS agent is out of scope, but the standardized information and data models for what is exposed are part of I2RS. Static System State: An I2RS agent needs access to static state on a routing element beyond what is contained in the routing subsystem. An example of such state is specifying queueing behavior for an interface or traffic. How the I2RS agent modifies or obtains this information is out of scope, but the standardized information and data models for what is exposed are part of I2RS. I2RS Agent: See the definition in Section 2. Atlas, et al. Expires December 25, 2014 [Page 7] Internet-Draft I2RS Arch June 2014 Application: A network application that needs to observe the network or manipulate the network to achieve its service requirements. I2RS Client: See the definition in Section 2. As can be seen in Figure 1, an I2RS client can communicate with multiple I2RS agents. An I2RS client may connect to one or more I2RS agents based upon its needs. Similarly, an I2RS agent may communicate with multiple I2RS clients - whether to respond to their requests, to send notifications, etc. Timely notifications are critical so that several simultaneously operating applications have up-to-date information on the state of the network. As can also be seen in Figure 1, an I2RS Agent may communicate with multiple clients. Each client may send the agent a variety of write operations. In order to keep the protocol simple, two clients should not attempt to write (modify) the same piece of information on an I2RS Agent. This is considered an error. However, such collisions may happen and section 7.8 (multi-headed control) describes how the I2RS agent resolves collision by first utilizing priority to resolve collisions, and second by servicing the requests in a first in, first served basis. The i2rs architecture includes this definition of behavior for this case simply for predictability not because this is an intended result. This predictability will simplify the error handling and suppress oscillations. If additional error cases beyond this simple treatment are required, these these error cases should be resolved by the network applications and management systems. In contrast, although multiple I2RS clients may need to supply data into the same list (e.g. a prefix or filter list), this is not considered an error and must be correctly handled. The nuances so that writers do not normally collide should be handled in the information models. The architectural goal for the I2RS is that such errors should produce predictable behaviors, and be reportable to interested clients. The details of the associated policy is discussed in Section 7.8. The same policy mechanism (simple priority per I2RS client) applies to interactions between the I2RS agent and the CLI/SNMP/NETCONF as described in Section 6.3. In addition it must be noted that there may be indirect interactions between write operations. A basic example of this is when two different but overlapping prefixes are written with different forwarding behavior. Detection and avoidance of such interactions is outside the scope of the I2RS work and is left to agent design and implementation. Atlas, et al. Expires December 25, 2014 [Page 8] Internet-Draft I2RS Arch June 2014 2. Terminology The following terminology is used in this document. agent or I2RS Agent: An I2RS agent provides the supported I2RS services from the local system's routing sub-systems by interacting with the routing element to provide specified behavior. The I2RS agent understands the I2RS protocol and can be contacted by I2RS clients. client or I2RS Client: A client implements the I2RS protocol, uses it to communicate with I2RS Agents, and uses the I2RS services to accomplish a task. It interacts with other elements of the policy, provisioning, and configuration system by means outside of the scope of the I2RS effort. It interacts with the I2RS agents to collect information from the routing and forwarding system. Based on the information and the policy oriented interactions, the I2RS client may also interact with I2RS agents to modify the state of their associated routing systems to achieve operational goals. An I2RS client can be seen as the part of an application that uses and supports I2RS and could be a software library. service or I2RS Service: For the purposes of I2RS, a service refers to a set of related state access functions together with the policies that control their usage. The expectation is that a service will be represented by a data-model. For instance, 'RIB service' could be an example of a service that gives access to state held in a device's RIB. read scope: The set of information which the I2RS client is authorized to read. The read scope specifies the access restrictions to both see the existence of data and read the value of that data. notification scope: The set of events and associated information that the I2RS Client can request be pushed by the I2RS Agent. I2RS Clients have the ability to register for specific events and information streams, but must be constrained by the access restrictions associated with their notification scope. write scope: The set of field values which the I2RS client is authorized to write (i.e. add, modify or delete). This access can restrict what data can be modified or created, and what specific value sets and ranges can be installed. scope: When unspecified as either read scope, write scope, or notification scope, the term scope applies to the read scope, write scope, and notification scope. RFC 3868 SUA October 2004 4.6. MTP3 Restart In the case where the MTP3 in the SG undergoes an MTP restart, event communication SHOULD be handled as follows: When the SG discovers SS7 network isolation, the SGPs send an indication to all concerned available ASPs (i.e., ASPs in the ASP- ACTIVE state) using DUNA messages for the concerned destinations. When the SG has completed the MTP Restart procedure, the SUA layer at the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any available/restricted SS7 destinations using the DAVA/DRST message. No message is necessary for those destinations still unavailable after the restart procedure. When the SUA layer at an ASP receives a DUNA message indicating SS7 destination unavailability at an SG, SCCP Users will receive an N- PCSTATE indication and will stop any affected traffic to this destination. When the SUA receives a DAVA/DRST message, SCCP Users will receive an N-PCSTATE indication and can resume traffic to the newly available SS7 destination via this SGP, provided the ASP is in the ASP-ACTIVE state toward this SGP. The ASP MAY choose to audit the availability of unavailable destinations by sending DAUD messages. This would be for example the case when an AS becomes active at an ASP and does not have current destination statuses. If MTP restart is in progress at the SG, the SGP returns a DUNA message for that destination, even if it received an indication that the destination became available or restricted. 4.7. SCCP - SUA Interworking at the SG 4.7.1. Segmenting / Reassembly When it is expected that signalling messages will not fit into a PDU of the most restrictive transport technology used (e.g., 272-SIF of MTP3), then segmenting/reassembly could be performed at the SG, ASP or IPSP. If the SG, ASP or IPSP is incapable of performing a necessary segmentation/reassembly, it can inform the peer of the failure using the appropriate error in a CLDR or RESRE/COERR message. 4.7.2. Support for Loadsharing Within an AS (identified by RK/RC parameters) several loadsharing ASPs may be active. Loughney, et al. Standards Track [Page 115] RFC 3868 SUA October 2004 However, to assure the correct processing of TCAP transactions or SCCP connections, the loadsharing scheme used at the SG must make sure that messages continuing or ending the transactions/connections arrive at the same ASP where the initial message (TC_Query, TC_Begin, CR) was sent to/received from. When the ASP can be identified uniquely based on RK parameters (e.g., unique DPC or GT), loadsharing is not required. When the ASPs in the AS share state or use an internal distribution mechanism, the SG must only take into account the in-sequence-delivery requirement. In case of SCCP CO traffic, when the coupled approach is used, loadsharing of messages other than CR is not required. If these assumptions cannot be made, both SG and ASP should support the following general procedure in a loadsharing environment. 4.7.2.1. Association Setup, ASP going active After association setup and registration, an ASP normally goes active for each AS it registered for. In the ASPAC message, the ASP includes a TID and/or DRN Label Parameter, if applicable for the AS in question. All the ASPs within the AS must specify a unique label at a fixed position in the TID or DRN parameter. The same ASPAC message is sent to each SG used for interworking with the SS7 network. The SG builds, per RK, a list of ASPs that have registered for it. The SG can now build up and update a distribution table for a certain Routing Context, any time the association is (re-)established and the ASP goes active. The SG has to perform some trivial plausibility checks on the parameters: - Start and End parameters values are between 0 and 31 for TID. - Start and End parameters values are between 0 and 23 for DRN - 0 < (Start - End + 1) <= 16 (label length maximum 16-bit) - Start values are the same for each ASP within a RC - End values are the same for each ASP within a RC - TID and DRN Label values must be unique across the RC If any of these checks fail, the SG refuses the ASPAC request, with an error, "Invalid loadsharing label." Loughney, et al. Standards Track [Page 116] RFC 3868 SUA October 2004 4.7.3. Routing and message distribution at the SG 4.7.3.1. TCAP traffic Messages not containing a destination (or "responding") TID, i.e., Query, Begin, Unidirectional, are loadshared among the available ASPs. Any scheme permitting a fair load distribution among the ASPs is allowed (e.g., round robin). When a destination TID is present, the SG extracts the label and selects the ASP that corresponds with it. If an ASP is not available, the SG may generate (X)UDTS "routing failure", if the return option is used. 4.7.3.2. SCCP Connection Oriented traffic Messages not containing a destination reference number (DRN), i.e., a Connection Request, MAY be loadshared among the available ASPs. The load distribution mechanism is an implementation issue. When a DRN is present, the SG extracts the label and selects the ASP that corresponds with it. If an ASP is not available, the SG discards the message. 4.7.4. Multiple SGs, SUA Relay Function It is important that each ASP send its unique label (within the AS) to each SGP. For a better robustness against association failures, the SGs MAY cooperate to provide alternative routes toward an ASP. Mechanisms for SG cooperation/coordination are outside of the scope of this document. 5. Examples of SUA Procedures The following sequence charts overview the procedures of SUA. These are meant as examples, they do not, in and of themselves, impose additional requirements upon an instance of SUA. 5.1. SG Architecture The sequences below outline logical steps for a variety of scenarios within a SG architecture. Please note that these scenarios cover a Primary/Backup configuration. Where there is a load-sharing configuration then the SGP can declare availability when 1 ASP issues ASPAC but can only declare unavailability when all ASPs have issued ASPIA. Loughney, et al. Standards Track [Page 117] RFC 3868 SUA October 2004 5.1.1. Establishment of SUA connectivity The following is established before traffic can flow. Each node is configured (via MIB, for example) with the connections that need to be setup. ASP-a1 ASP-a2 SG SEP (Primary) (Backup) |------Establish SCTP Association------| |--Estab. SCTP Ass--| |--Align SS7 link---| +----------------ASP Up----------------> <--------------ASP Up Ack--------------+ +------ASP Up-------> <---ASP Up Ack------+ +-------------ASP Active---------------> <----------ASP Active Ack--------------+ <----------NTFY (ASP Active)-----------+ <-NTFY (ASP Active)-+ +--------SSA--------> <--------SSA--------+ <-----------------DAVA-----------------+ +-----------------CLDT-----------------> +--------UDT--------> 5.1.2. Fail-over scenarios The following sequences address fail-over of SEP and ASP. 5.1.2.1. SEP Fail-over The SEP knows that the SGP is 'concerned' about its availability. Similarly, the SGP knows that ASP-a1 is concerned about the SEPs availability. ASP-a1 ASP-a2 SG SEP (Primary) (Backup) <--------SSP--------+ <-----------------DUNA-----------------+ +-----------------DAUD-----------------> +--------SST--------> Loughney, et al. Standards Track [Page 118] RFC 3868 SUA October 2004 5.1.2.2. Successful ASP Fail-over scenario The following is an example of a successful fail-over scenario, where there is a fail-over from ASP-a1 to ASP-a2, i.e., Primary to Backup. During the fail-over, the SGP buffers any incoming data messages from the SEP, forwarding them when the Backup becomes available. ASP-a1 ASP-a2 SG SEP (Primary) (Backup) +-------------ASP Inactive-------------> <-----------ASP Inactive ACK-----------+ <--------------------NTFY (AS Pending)-+ <-NTFY (AS Pending)-+ +----ASP Active-----> <--ASP Active Ack---+ <-NTFY (AS Active)--+ <----------NTFY (AS Active)------------+ 5.1.2.3. Unsuccessful ASP Fail-over scenario ASP-a1 ASP-a2 SG SEP (Primary) (Backup) +-------------ASP Inactive-------------> <-----------ASP Inactive ACK-----------+ <--------------------NTFY (AS Pending)-+ <--NTFY (AS Pending)-+ After some time elapses (i.e., timeout). +--------SSP--------> <--------SST--------+ <-------------------NTFY (AS Inactive)-+ <-NTFY (AS Inactive)-+ 5.2. IPSP Examples The sequences below outline logical steps for a variety of scenarios within an IP-IP architecture. Please note that these scenarios cover a Primary/Backup configuration. Where there is a load-sharing configuration then the AS can declare availability when 1 ASP issues ASPAC but can only declare unavailability when all ASPs have issued ASPIA. 5.2.1. Establishment of SUA connectivity The following shows an example establishment of SUA connectivity. In this example, each IPSP consists of an Application Server and two ASPs. The following is established before SUA traffic can flow. A connectionless flow is shown for simplicity. Loughney, et al. Standards Track [Page 119] RFC 3868 SUA October 2004 Establish SCTP Connectivity - as per RFC 2960. Note that SCTP connections are bidirectional. The endpoint that establishes SCTP connectivity MUST also establish UA connectivity (see RFC 2960, section 5.2.1 for handling collisions) [2960]. IP SEP A IP SEP B AS A AS B ASP-a1 ASP-a2 ASP-b2 ASP-b1 [All ASPs are in the ASP-DOWN state] +-------------------------------ASP Up--------------------------Atlas, et al. Expires December 25, 2014 [Page 9] Internet-Draft I2RS Arch June 2014 resources: A resource is an I2RS-specific use of memory, storage, or execution that a client may consume due to its I2RS operations. The amount of each such resource that a client may consume in the context of a particular agent may be constrained based upon the client's security role. An example of such a resource could include the number of notifications registered for. These are not protocol-specific resources or network-specific resources. role or security role: A security role specifies the scope, resources, priorities, etc. that a client or agent has. identity: A client is associated with exactly one specific identity. State can be attributed to a particular identity. It is possible for multiple communication channels to use the same identity; in that case, the assumption is that the associated client is coordinating such communication. secondary identity: An I2RS Client may supply a secondary opaque identity that is not interpreted by the I2RS Agent. An example use is when the I2RS Client is a go-between for multiple applications and it is necessary to track which application has requested a particular operation. 3. Key Architectural Properties Several key architectural properties for the I2RS protocol are elucidated below (simplicity, extensibility, and model-driven programmatic interfaces). However, some architecture principles such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement] and because the performance and scaling requires varies based on the particular use- cases. 3.1. Simplicity There have been many efforts over the years to improve the access to the information available to the routing and forwarding system. Making such information visible and usable to network management and applications has many well-understood benefits. There are two related challenges in doing so. First, the quantity and diversity of information potentially available is very large. Second, the variation both in the structure of the data and in the kinds of operations required tends to introduce protocol complexity. While the types of operations contemplated here are complex in their nature, it is critical that I2RS be easily deployable and robust. Adding complexity beyond what is needed to satisfy well known and understood requirements would hinder the ease of implementation, the Atlas, et al. Expires December 25, 2014 [Page 10] Internet-Draft I2RS Arch June 2014 robustness of the protocol, and the deployability of the protocol. Overly complex data models tend to ossify information sets by attempting to describe and close off every possible option, complicating extensibility. Thus, one of the key aims for I2RS is the keep the protocol and modeling architecture simple. So for each architectural component or aspect, we ask ourselves "do we need this complexity, or is the behavior merely nice to have?" Protocol parsimony is clearly a goal. 3.2. Extensibility Naturally, extensibility of the protocol and data model is very important. In particular, given the necessary scope limitations of the initial work, it is critical that the initial design include strong support for extensibility. The scope of the I2RS work is being restricted in the interests of achieving a deliverable and deployable result. The I2RS Working Group is modeling only a subset of the data of interest. It is clearly desirable for the data models defined in the I2RS to be useful in more general settings. It should be easy to integrate data models from the I2RS with other data. Other work should be able to easily extend it to represent additional aspects of the network elements or network systems. This reinforces the criticality of designing the data models to be highly extensible, preferably in a regular and simple fashion. The I2RS Working Group is defining operations for the I2RS protocol. It would be optimistic to assume that more and different ones may not be needed when the scope of I2RS increases. Thus, it is important to consider extensibility not only of the underlying services' data models, but also of the primitives and protocol operations. 3.3. Model-Driven Programmatic Interfaces A critical component of I2RS is the standard information and data models with their associated semantics. While many components of the routing system are standardized, associated data models for them are not yet available. Instead, each router uses different information, different mechanisms, and different CLI which makes a standard interface for use by applications extremely cumbersome to develop and maintain. Well-known data modeling languages exist and may be used for defining the data models for I2RS. There are several key benefits for I2RS in using model-driven architecture and protocol(s). First, it allows for transferring data-models whose content is not explicitly implemented or Atlas, et al. Expires December 25, 2014 [Page 11] Internet-Draft I2RS Arch June 2014 understood. Second, tools can automate checking and manipulating data; this is particularly valuable for both extensibility and for the ability to easily manipulate and check proprietary data-models. The different services provided by I2RS can correspond to separate data-models. An I2RS agent may indicate which data-models are supported. 4. Security Considerations This I2RS architecture describes interfaces that clearly require serious consideration of security. First, here is a brief description of the assumed security environment for I2RS. The I2RS Agent associated with a Routing Element is a trusted part of that Routing Element. For example, it may be part of a vendor-distributed signed software image for the entire Routing Element or it may be trusted signed application that an operator has installed. The I2RS Agent is assumed to have a separate authentication and authorization channel by which it can validate both the identity and permissions associated with an I2RS Client. To support numerous and speedy interactions between the I2RS Agent and I2RS Client, it is assumed that the I2RS Agent can also cache that particular I2RS Clients are trusted and their associated authorized scope. This implies that the permission information may be old either in a pull model until the I2RS Agent re-requests it, or in a push model until the authentication and authorization channel can notify the I2RS Agent of changes. An I2RS Client is not automatically trustworthy. It has identity information and applications using that I2RS Client should be aware of the scope limitations of that I2RS Client. If the I2RS Client is acting as a broker for multiple applications, managing the security, authentication and authorization for that communication is out of scope; nothing prevents I2RS and a separate authentication and authorization channel from being used. Regardless of mechanism, an I2RS Client that is acting as a broker is responsible for determining that applications using it are trusted and permitted to make the particular requests. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, privacy and replay protection. Appropriate selection of a default required transport protocol is the preferred way of meeting these requirements. Atlas, et al. Expires December 25, 2014 [Page 12] Internet-Draft I2RS Arch June 2014 Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection. Similarly, an information stream of interface statistics may not even require guaranteed delivery. In Section 7.2, more reasoning for multiple communication channels is provided. From the security perspective, it is critical to realize that an I2RS Agent may open a new communication channel based upon information provided by an I2RS Client (as described in Section 7.2). For example, a I2RS client may request notifications of certain events and the agent will open a communication channel to report such events. Therefore, to avoid an indirect attack, such a request must be done in the context of an authenticated and authorized client whose communications cannot have been altered. 4.1. Identity and Authentication As discussed above, all control exchanges between the I2RS client and agent should be authenticated and integrity protected (such that the contents cannot be changed without detection). Further, manipulation of the system must be accurately attributable. In an ideal architecture, even information collection and notification should be protected; this may be subject to engineering tradeoffs during the design. I2RS clients may be operating on behalf of other applications. While those applications' identities are not needed for authentication or authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations to support functionality such as accounting and troubleshooting. 4.2. Authorization All operations using I2RS, both observation and manipulation, should be subject to appropriate authorization controls. Such authorization is based on the identity and assigned role of the I2RS client performing the operations and the I2RS agent in the network element. I2RS Agents, in performing information collection and manipulation, will be acting on behalf of the I2RS clients. As such, each operation authorization will be based on the lower of the two permissions of the agent itself and of the authenticated client. The mechanism by which this authorization is applied within the device is outside of the scope of I2RS. Atlas, et al. Expires December 25, 2014 [Page 13] Internet-Draft I2RS Arch June 2014 The appropriate or necessary level of granularity for scope can depend upon the particular I2RS Service and the implementation's granularity. An approach to a similar access control problem is defined in the NetConf Access Control Model[RFC6536]; it allows arbitrary access to be specified for a data node instance identifier while defining meaningful manipulable defaults. The ability to specify one or more groups or roles that a particular I2RS Client belongs and then define access controls in terms of those groups or roles is expected. When a client is authenticated, its group or role membership should be provided to the I2RS Agent. The set of access control rules that an I2RS Agent uses would need to be either provided via Local Config, exposed as an I2RS Service for manipulation by authorized clients, or via some other method. 5. Network Applications and I2RS Client I2RS is expected to be used by network-oriented applications in different architectures. While the interface between a network- oriented application and the I2RS client is outside the scope of I2RS, considering the different architectures is important to sufficiently specify I2RS. In the simplest architecture, a network-oriented application has an I2RS client as a library or driver for communication with routing elements. In the broker architecture, multiple network-oriented applications communicate in an unspecified fashion to a broker application that contains an I2RS Client. That broker application requires additional functionality for authentication and authorization of the network- oriented applications; such functionality is out of scope for I2RS but similar considerations to those described in Section 4.2 do apply. As discussed in Section 4.1, the broker I2RS Client should determine distinct opaque identifiers for each network-oriented application that is using it. The broker I2RS Client can pass along the appropriate value as a secondary identifier which can be used for tracking attribution of operations. In a third architecture, a routing element or network-oriented application that uses an I2RS Client to access services on a different routing element may also contain an I2RS agent to provide services to other network-oriented applications. However, where the needed information and data models for those services differs from that of a conventional routing element, those models are, at least initially, out of scope for I2RS. Below is an example of such a network application Atlas, et al. Expires December 25, 2014 [Page 14] Internet-Draft I2RS Arch June 2014 5.1. Example Network Application: Topology Manager A Topology Manager includes an I2RS client that uses the I2RS data models and protocol to collect information about the state of the network by communicating directly with one or more I2RS agents. From these I2RS agents, the Topology Manager collects routing configuration and operational data, such as interface and label- switched path (LSP) information. In addition, the Topology Manager may collect link-state data in several ways - either via I2RS models, by peering with BGP-LS[I-D.ietf-idr-ls-distribution] or listening into the IGP. The set of functionality and collected information that is the Topology Manager may be embedded as a component of a larger application, such as a path computation application. As a stand- alone application, the Topology Manager could be useful to other network applications by providing a coherent picture of the network state accessible via another interface. That interface might use the same I2RS protocol and could provide a topology service using extensions to the I2RS data models. 6. I2RS Agent Role and Functionality The I2RS Agent is part of a routing element. As such, it has relationships with that routing element as a whole, and with various components of that routing element. 6.1. Relationship to its Routing Element A Routing Element may be implemented with a wide variety of different architectures: an integrated router, a split architecture, distributed architecture, etc. The architecture does not need to affect the general I2RS agent behavior. For scalability and generality, the I2RS agent may be responsible for collecting and delivering large amounts of data from various parts of the routing element. Those parts may or may not actually be part of a single physical device. Thus, for scalability and robustness, it is important that the architecture allow for a distributed set of reporting components providing collected data from the I2RS agent back to the relevant I2RS clients. There may be multiple I2RS Agents within the same router. In such a case, they must have non- overlapping sets of information which they manipulate. Atlas, et al. Expires December 25, 2014 [Page 15] Internet-Draft I2RS Arch June 2014 6.2. I2RS State Storage State modification requests are sent to the I2RS agent in a routing element by I2RS clients. The I2RS agent is responsible for applying these changes to the system, subject to the authorization discussed above. The I2RS agent will retain knowledge of the changes it has applied, and the client on whose behalf it applied the changes. The I2RS agent will also store active subscriptions. These sets of data form the I2RS data store. This data is retained by the agent until the state is removed by the client, overridden by some other operation such as CLI, or the device reboots. Meaningful logging of the application and removal of changes is recommended. I2RS applied changes to the routing element state will not be retained across routing element reboot. The I2RS data store is not preserved across routing element reboots; thus the I2RS agent will not attempt to reapply such changes after a reboot. 6.2.1. I2RS Agent Failure It is expected that an I2RS Agent may fail independently of the associated routing element. This could happen because I2RS is disabled on the routing element or because the I2RS Agent, a separate process or even running on a separate processor, experiences an unexpected failure. Just as routing state learned from a failed source is removed, the ephemeral I2RS state will usually be removed shortly after the failure is detected or as part of a graceful shutdown process. To handle I2RS Agent failure, the I2RS Agent must use two different notifications. NOTIFICATION_I2RS_AGENT_STARTING: This notification identifies that the associated I2RS Agent has started. It includes an agent-boot- count that indicates how many times the I2RS Agent has restarted since the associated routing element restarted. The agent-boot- count allows an I2RS Client to determine if the I2RS Agent has restarted. NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that the associated I2RS Agent is shutting down gracefully. Ephemeral state will be removed. It can optionally include a timestamp indicating when the I2RS Agent will shutdown. Use of this timestamp assumes that time synchronization has been done and the timestamp should not have granularity finer than one second because better accuracy of shutdown time is not guaranteed. There are two different failure types that are possible and each has different behavior. > <-----------------------------ASP Up Ack------------------------+ +--------------ASP Up---------------> <------------ASP Up Ack-------------+ +---------------------------ACTIVE-------------------------------> <-------------------------ACTIVE Ack-----------------------------+ [Traffic can now flow directly between ASPs] +-----------------------------CLDT-------------------------------> 5.2.2. Fail-over scenarios The following sequences address fail-over of ASP. 5.2.2.1. Successful ASP Fail-over scenario The following is an example of a successful fail-over scenario, where there is a fail-over from ASP-a1 to ASP-a2, i.e., Primary to Backup. Since data transfer passes directly between peer ASPs, ASP-b1 is notified of the fail-over of ASP-a1 and buffers outgoing data messages until ASP-a2 becomes available. IP SEP A IP SEP B ASP-a1 ASP-a2 ASP-b2 ASP-b1 +-----------------------------ASP Inact------------------------> <---------------------------ASP Inact Ack----------------------+ <---------------NTFY (ASP-a1 Inactive)--------------+ +---------------------ASP Act-----------------------> <-------------------ASP Act Ack---------------------+ Loughney, et al. Standards Track [Page 120] RFC 3868 SUA October 2004 5.2.2.2. Unsuccessful ASP Fail-over scenario The sequence is the same as 5.2.2.1 except that, since the backup fails to come in then, the Notify messages declaring the availability of the backup are not sent. 6. Security Considerations The security considerations discussed for the 'Security Considerations for SIGTRAN Protocols' [3788] document apply to this document. 7. IANA Considerations 7.1. SCTP Payload Protocol ID IANA has assigned a SUA value for the Payload Protocol Identifier in the SCTP DATA chunk. The following SCTP Payload Protocol Identifier is registered: SUA "4" The SCTP Payload Protocol Identifier value "4" SHOULD be included in each SCTP DATA chunk, to indicate that the SCTP is carrying the SUA protocol. The value "0" (unspecified) is also allowed but any other values MUST not be used. This Payload Protocol Identifier is not directly used by SCTP but MAY be used by certain network entities to identify the type of information being carried in a DATA chunk. The User Adaptation peer MAY use the Payload Protocol Identifier, as a way of determining additional information about the data being presented to it by SCTP. 7.2. Port Number IANA has registered SCTP Port Number 14001 for SUA. It is recommended that SGPs use this SCTP port number for listening for new connections. SGPs MAY also use statically configured SCTP port numbers instead. 7.3. Protocol Extensions This protocol may also be extended through IANA in three ways: - Through definition of additional message classes. - Through definition of additional message types. - Through definition of additional message parameters. Loughney, et al. Standards Track [Page 121] RFC 3868 SUA October 2004 The definition and use of new message classes, types and parameters is an integral part of SIGTRAN adaptation layers. Thus, these extensions are assigned by IANA through an IETF Consensus action as defined in [2434]. The proposed extension MUST in no way adversely affect the general working of the protocol. A new registry has been created by IANA to allow the protocol to be extended. 7.3.1. IETF Defined Message Classes The documentation for a new message class MUST include the following information: (a) A long and short name for the message class; (b) A detailed description of the purpose of the message class. 7.3.2. IETF Defined Message Types Documentation of the message type MUST contain the following information: (a) A long and short name for the new message type; (b) A detailed description of the structure of the message. (c) A detailed definition and description of intended use of each field within the message. (d) A detailed procedural description of the use of the new message type within the operation of the protocol. (e) A detailed description of error conditions when receiving this message type. When an implementation receives a message type which it does not support, it MUST respond with an Error (ERR) message, with an Error Code = Unsupported Message Type. 7.3.4. IETF-defined TLV Parameter Extension Documentation of the message parameter MUST contain the following information: (a) Name of the parameter type. (b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described earlier in the document. (c) Detailed definition of each component of the parameter value. Loughney, et al. Standards Track [Page 122] RFC 3868 SUA October 2004 (d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same message type. 8. Timer Values Ta 2 seconds Tr 2 seconds T(ack) 2 seconds T(ias) Inactivity Send timer 7 minutes T(iar) Inactivity Receive timer 15 minutes T(beat) Heartbeat Timer 30 seconds 9. Acknowledgements The authors would like to thank (in alphabetical order) Richard Adams, Javier Pastor-Balbas, Andrew Booth, Martin Booyens, F. Escobar, S. Furniss Klaus Gradischnig, Miguel A. Garcia, Marja-Liisa Hamalainen, Sherry Karl, S. Lorusso, Markus Maanoja, Sandeep Mahajan, Ken Morneault, Guy Mousseau, Chirayu Patel, Michael Purcell, W. Sully, Michael Tuexen, Al Varney, Tim Vetter, Antonio Villena, Ben Wilson, Michael Wright and James Yu for their insightful comments and suggestions. 10. References 10.1. Normative References [1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [3788] Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas, "Security Considerations for Signaling Transport (SIGTRAN) Protocols", RFC 3788, June 2004. Loughney, et al. Standards Track [Page 123] RFC 3868 SUA October 2004 [ANSI SCCP] ANSI T1.112 "Signalling System Number 7 - Signalling Connection Control Part". [ITU SCCP] ITU-T Recommendations Q.711-714, "Signalling System No. 7 (SS7) - Signalling Connection Control Part (SCCP)." ITU-T Telecommunication Standardization Sector of ITU, formerly CCITT, Geneva (July 1996). 10.2. Informative References [2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework Architecture for Signalling Transport", RFC 2719, October 1999. [3761] Falstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [ANSI TCAP] ANSI T1.114 'Signalling System Number 7 - Transaction Capabilities Application Part' [ITU TCAP] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) - Transaction Capabilities (TCAP).' [RANAP] 3G TS 25.413 V3.5.0 (2001-03) 'Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface RANAP Signalling' Loughney, et al. Standards Track [Page 124] RFC 3868 SUA October 2004 Appendix A. Signalling Network Architecture A.1. Generalized Peer-to-Peer Network Architecture Figure 3 shows an example network architecture that can support robust operation and fail-over. There needs to be some management resources at the AS to manage traffic. *********** * AS1 * * +-----+ * SCTP Associations * |ASP1 +-------------------+ * +-----+ * | *********** * * | * AS3 * * +-----+ * | * +-----+ * * |ASP2 +-----------------------------------------+ASP1 | * * +-----+ * | * +-----+ * * * | * * * +-----+ * | * +-----+ * * |ASP3 | * +--------------------------+ASP2 | * * +-----+ * | | * +-----+ * *********** | | *********** | | *********** | | *********** * AS2 * | | * AS4 * * +-----+ * | | * +-----+ * * |ASP1 +--------------+ +---------------------+ASP1 | * * +-----+ * * +-----+ * * * * * * +-----+ * * +-----+ * * |ASP2 +-----------------------------------------+ASP1 | * * +-----+ * * +-----+ * * * *********** * +-----+ * * |ASP3 | * * +-----+ * * * *********** Figure 3: Generalized Architecture In this example, the Application Servers are shown residing within one logical box, with ASPs located inside. In fact, an AS could be distributed among several hosts. In such a scenario, the host should share state as protection in the case of a failure. This is out of scope of this protocol. Additionally, in a distributed system, one ASP could be registered to more than one AS. This document should not restrict such systems - though such a case in not specified. Loughney, et al. Standards Track [Page 125] RFC 3868 SUA October 2004 A.2. Signalling Gateway Network Architecture When interworking between SS7 and IP domains is needed, the SGP acts as the gateway node between the SS7 network and the IP network. The SGP will transport SCCP-user signalling traffic from the SS7 network to the IP-based signalling nodes (for example IP-resident Databases). The Signalling Gateway can be considered as a group of Application Servers with additional functionality to interface toward an SS7 network. The SUA protocol should be flexible enough to allow different configurations and transport technology to allow the network operators to meet their operation, management and performance requirements. An ASP may be connected to multiple SGPs (see figure 4). In such a case, a particular SS7 destination may be reachable via more than SG, therefore, more than one route. Given that proper SLS selection, loadsharing, and SG selection based on point code availability is performed at the ASP, it will be necessary for the ASP to maintain the status of each distant SGPs to which it communicates on the basis of the SG through which it may route. Loughney, et al. Standards Track [Page 126] RFC 3868 SUA October 2004 Signalling Gateway SCTP Associations +----------+ ************** | SG1 | * AS3 * | ******** | * ******** * | * SGP11+--------------------------------------------+ ASP1 * * | ******** | / * ******** * | ******** | | * ******** * | * SGP12+--------------------------------------------+ ASP2 * * | ******** | \ / | * ******** * +----------+ \ | | * . * \ | | * . * +---------- \ | | * . * | SG2 | \ | | * . * | ******** | \ | | * ******** * | * SGP21+---------------------------------+-+ * * ASPN * * | ******** | \ * ******** * | ******** | \ ************** | * SGP22+---+--+ \ | ******** | | | \ ************** +----------+ | | \ * AS4 * | | \ * ******** * | +-------------------------------------+ ASP1 * * | * ******** * | * . * | * . * | * * | * ******** * +----------------------------------------+ ASPn * * * ******** * ************** Figure 4: Signalling Gateway Architecture The pair of SGs can either operate as replicated endpoints or as replicated relay points from the SS7 network point of view. Replicated endpoints: the coupling between the SGs and the ASPs when the SGs act as replicated endpoints is an implementation issue. Replicated relay points: in normal circumstances, the path from SEP to ASP will always go via the same SGP when in-sequence-delivery is requested. However, linkset failures may cause MTP to reroute to the other SG. Loughney, et al. Standards Track [Page 127] RFC 3868 SUA October 2004 A.3. Signalling Gateway Message Distribution Recommendations A.3.1. Connectionless Transport By means of configuration, the SG knows the local SCCP-user is actually represented by an AS, and serviced by a set of ASPs working in n+k redundancy mode. An ASP is selected and a CLDT message is sent on the appropriate SCTP association/stream. The selection criterion can be based on a round robin mechanism, or any other method that guarantees a balanced loadsharing over the active ASPs. However, when TCAP messages are transported, load sharing is only possible for the first message in a TCAP dialogue (TC_Begin, TC_Query, TC_Unidirectional). All other TCAP messages in the same dialogue are sent to the same ASP that was selected for the first message, unless the ASPs are able to share state and maintain sequenced delivery. To this end, the SGP needs to know the TID allocation policy of the ASPs in a single AS: - State sharing - Fixed range of TIDs per ASP in the AS This information may be provisioned in the SG, or may be dynamically exchanged via the ASP_Active message. An example for an INAP/TCAP message exchange between SEP and ASP is given below. Address information in CLDT message (e.g., TC_Query) from SGP to ASP, with association ID = SG-ASP, Stream ID based on sequence control and possibly other parameters, e.g., OPC: - Routing Context: based on SS7 Network ID and AS membership, so that the message can be transported to the correct ASP. - Source address: valid combination of SSN, PC and GT, as needed for back routing to the SEP. - Destination address: at least SSN, to select the SCCP/SUA-user at the ASP. Address information in CLDT message (e.g., TC_Response) from ASP to SG, with association ID = ASP-SG, stream ID selected by implementation dependent means with regards to in-sequence-delivery: - Routing Context: as received in previous message. - Source address: unique address provided so that when used as the SCCP called party address in the SEP, it must yield the same AS, the SSN might be sufficient. Loughney, et al. Standards Track [Page 128] RFC 3868 SUA October 2004 Atlas, et al. Expires December 25, 2014 [Page 16] Internet-Draft I2RS Arch June 2014 Unexpected failure: In this case, the I2RS Agent has unexpectedly crashed and thus cannot notify its clients of anything. Since I2RS does not require a persistent connection between the I2RS Client and I2RS Agent, it is necessary to have a mechanism for the I2RS Agent to notify I2RS Clients that had subscriptions or written ephemeral state; such I2RS Clients should be cached by the I2RS Agent's system in persistent storage. When the I2RS Agent starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each cached I2RS Client. Graceful failure: In this case, the I2RS Agent can do specific limited work as part of the process of being disabled. The I2RS Agent Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all its cached I2RS Clients. 6.2.2. Starting and Ending When an I2RS client applies changes via the I2RS protocol, those changes are applied and left until removed or the routing element reboots. The network application may make decisions about what to request via I2RS based upon a variety of conditions that imply different start times and stop times. That complexity is managed by the network application and is not handled by I2RS. 6.2.3. Reversion An I2RS Agent may decide that some state should no longer be applied. An I2RS Client may instruct an Agent to remove state it has applied. In all such cases, the state will revert to what it would have been without the I2RS; that state is generally whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple alternative states, nor try to determine which one among such a plurality it should fall back to. Thus, the model followed is not like the RIB, where multiple routes are stored at different preferences. An I2RS Client may register for notifications, subject to its notification scope, regarding state modification or removal by a particular I2RS Client. 6.3. Interactions with Local Config Changes may originate from either Local Config or from I2RS. The modifications and data stored by I2RS are separate from the local device configuration, but conflicts between the two must be resolved in a deterministic manner that respects operator-applied policy. That policy can determine whether Local Config overrides a particular I2RS client's request or vice versa. To achieve this end, either by Atlas, et al. Expires December 25, 2014 [Page 17] Internet-Draft I2RS Arch June 2014 default Local Config always wins or, optionally, a routing element may permit a priority to be configured on the device for the Local Config mechanism. The policy mechanism in the later case is comparing the I2RS client's priority with that priority assigned to the Local Config. When the Local Config always wins, some communication between that subsystem and the I2RS Agent is still necessary. That communication contains the details of each specific device configuration change that the I2RS Agent is permitted to modify. In addition, when the system determines, that a client's I2RS state is preempted, the I2RS agent must notify the affected I2RS clients; how the system determines this is implementation-dependent. It is critical that policy based upon the source is used because the resolution cannot be time-based. Simply allowing the most recent state to prevail could cause race conditions where the final state is not repeatably deterministic. 6.4. Routing Components and Associated I2RS Services For simplicity, each logical protocol or set of functionality that can be compactly described in a separable information and data model is considered as a separate I2RS Service. A routing element need not implement all routing components described nor provide the associated I2RS services. When a full implementation is not mandatory, an I2RS Service should include a capability model so that implementations can indicate which parts of the service are supported. Each I2RS Service requires an information model that describes at least the following: data that can be read, data that can be written, notifications that can be subscribed to, and the capability model mentioned above. The initial services included in the I2RS architecture are as follows. Atlas, et al. Expires December 25, 2014 [Page 18] Internet-Draft I2RS Arch June 2014 *************************** ************** ***************** * I2RS Protocol * * * * Dynamic * * * * Interfaces * * Data & * * +--------+ +-------+ * * * * Statistics * * | Client | | Agent | * ************** ***************** * +--------+ +-------+ * * * ************** ************* *************************** * * * * * Policy * * Base QoS * ******************** ******** * Templates * * Templates * * +--------+ * * * * * ************* * BGP | BGP-LS | * * PIM * ************** * +--------+ * * * ******************** ******** **************************** * MPLS +---------+ +-----+ * ********************************** * | RSVP-TE | | LDP | * * IGPs +------+ +------+ * * +---------+ +-----+ * * +--------+ | OSPF | | ISIS | * * +--------+ * * | Common | +------+ +------+ * * | Common | * * +--------+ * * +--------+ * ********************************** **************************** ************************************************************** * RIB Manager * * +-------------------+ +---------------+ +------------+ * * | Unicast/multicast | | Policy-Based | | RIB Policy | * * | RIBs & LIBs | | Routing | | Controls | * * | route instances | | (ACLs, etc) | +------------+ * * +-------------------+ +---------------+ * ************************************************************** Figure 2: Anticipated I2RS Services There are relationships between different I2RS Services - whether those be the need for the RIB to refer to specific interfaces, the desire to refer to common complex types (e.g. links, nodes, IP addresses), or the ability to refer to implementation-specific functionality (e.g. pre-defined templates to be applied to interfaces or for QoS behaviors that traffic is direct into). Section 6.4.5 discusses information modeling constructs and the range of relationship types that are applicable. 6.4.1. Routing and Label Information Bases Routing elements may maintain one or more Information Bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast. Another such example includes the MPLS Label Information Bases, per-platform- or per-interface." This Atlas, et al. Expires December 25, 2014 [Page 19] Internet-Draft I2RS Arch June 2014 functionality, exposed via an I2RS Service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources, so as to safely change the system state. Conceptually, this can be handled by having the I2RS Agent communicate with a RIB Manager as a separate routing source. The point-to-multipoint state added to the RIB does not need to match to well-known multicast protocol installed state. The I2RS Agent can create arbitrary replication state in the RIB, subject to the advertised capabilities of the routing element. 6.4.2. IGPs, BGP and Multicast Protocols A separate I2RS Service can expose each routing protocol on the device. Such I2RS services may include a number of different kinds of operations: o reading the various internal RIB(s) of the routing protocol is often helpful for understanding the state of the network. Directly writing to these protocol-specific RIBs or databases is out of scope for I2RS. o reading the various pieces of policy information the particular protocol instance is using to drive its operations. o writing policy information such as interface attributes that are specific to the routing protocol or BGP policy that may indirectly manipulate attributes of routes carried in BGP. o writing routes or prefixes to be advertised via the protocol. o joining/removing interfaces from the multicast trees o subscribing to an information stream of route changes o receiving notifications about peers coming up or going down For example, the interaction with OSPF might include modifying the local routing element's link metrics, announcing a locally-attached prefix, or reading some of the OSPF link-state database. However, direct modification of the link-state database MUST NOT be allowed in order to preserve network state consistency. 6.4.3. MPLS I2RS Services will be needed to expose the protocols that create transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, Atlas, et al. Expires December 25, 2014 [Page 20] Internet-Draft I2RS Arch June 2014 L2VPNs, etc). This should include all local information about LSPs originating in, transiting, or terminating in this Routing Element. 6.4.4. Policy and QoS Mechanisms Many network elements have separate policy and QoS mechanisms, including knobs which affect local path computation and queue control capabilities. These capabilities vary widely across implementations, and I2RS cannot model the full range of information collection or manipulation of these attributes. A core set does need to be included in the I2RS information models and supported in the expected interfaces between the I2RS Agent and the network element, in order to provide basic capabilities and the hooks for future extensibility. By taking advantage of extensibility and sub-classing, information models can specify use of a basic model that can be replaced by a more detailed model. 6.4.5. Information Modeling, Device Variation, and Information Relationships I2RS depends heavily on information models of the relevant aspects of the Routing Elements to be manipulated. These models drive the data models and protocol operations for I2RS. It is important that these informational models deal well with a wide variety of actual implementations of Routing Elements, as seen between different products and different vendors. There are three ways that I2RS information models can address these variations: class or type inheritance, optional features, and templating. 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance Information modelled by I2RS from a Routing Element can be described in terms of classes or types or object. Different valid inheritance definitions can apply. What is appropriate for I2RS to use is not determined in this architecture; for simplicity, class and subclass will be used as the example terminology. This I2RS architecture does require the ability to address variation in Routing Elements by allowing information models to define parent or base classes and subclasses. The base or parent class defines the common aspects that all Routing Elements are expected to support. Individual subclasses can represent variations and additional capabilities. When applicable, there may be several levels of refinement. The I2RS protocol can then provide mechanisms to allow an I2RS client to determine which classes a given I2RS Agent has available. Clients which only want basic capabilities can operate purely in terms of base or parent Atlas, et al. Expires December 25, 2014 [Page 21] Internet-Draft I2RS Arch June 2014 classes, while a client needing more details or features can work with the supported sub-class(es). As part of I2RS information modeling, clear rules should be specified for how the parent class and subclass can relate; for example, what changes can a subclass make to its parent? The description of such rules should be done so that it can apply across data modeling tools until the I2RS data modeling language is selected. 6.4.5.2. Managing Variation: Optionality I2RS Information Models must be clear about what aspects are optional. For instance, must an instance of a class always contain a particular data field X? If so, must the client provide a value for X when creating the object or is there a well-defined default value? From the Routing Element perspective, in the above example, each Information model should provide information that: o Is X required for the data field to be accepted and applied? o If X is optional, then how does "X" as an optional portion of data field interact with the required aspects of the data field? o Does the data field have defaults for the mandatory portion of the field and the optional portions of the field o Is X required to be within a particular set of values (E.g. range, length of strings)? The information model needs to be clear about what read or write values are set by client and what responses or actions are required by the agent. It is important to indicate what is required or optional in client values and agent responses/actions. 6.4.5.3. Managing Variation: Templating A template is a collection of information to address a problem; it cuts across the notions of class and object instances. A template provides a set of defined values for a set of information fields and can specify a set of values that must be provided to complete the template. Further, a flexible template scheme may that some of the defined values can be over-written. For instance, assigning traffic to a particular service class might be done by specifying a template Queueing with a parameter to indicate Gold, Silver, or Best Effort. The details of how that is carried out are not modeled. This does assume that the necessary templates are made available on the Routing Element via some Atlas, et al. Expires December 25, 2014 [Page 22] Internet-Draft I2RS Arch June 2014 mechanism other than I2RS. The idea is that by providing suitable templates for tasks that need to be accomplished, with templates implemented differently for different kinds of Routing Elements, the client can easily interact with the Routing Element without concern for the variations which are handled by values included in the template. If implementation variation can be exposed in other ways, templates may not be needed. However, templates themselves could be objects referenced in the protocol messages, with Routing Elements being configured with the proper templates to complete the operation. This is a topic for further discussion. 6.4.5.4. Object Relationships Objects (in a Routing Element or otherwise) do not exist in isolation. They are related to each other. One of the important things a class definition does is represent the relationships between instances of different classes. These relationships can be very simple, or quite complicated. The following lists the information relationships that the information models need to support. [[Editors' note: All of these are for discussion, and it is expected that the list may be changed during WG discussion.]] 6.4.5.4.1. Initialization The simplest relationship is that one object instance is initialized by copying another. For example, one may have an object instance that represents the default setup for a tunnel, and all new tunnels have fields copied from there if they are not set as part of establishment. This is closely related to the templates discussed above, but not identical. Since the relationship is only momentary it is often not formally represented in modeling, but only captured in the semantic description of the default object. 6.4.5.4.2. Correlation Identification Often, it suffices to indicate in one object that it is related to a second object, without having a strong binding between the two. So an Identifier is used to represent the relationship. This can be used to allow for late binding, or a weak binding that does not even need to exist. A policy name in an object might indicate that if a policy by that name exists, it is to be applied under some circumstance. In modeling this is often represented by the type of the value. Atlas, et al. Expires December 25, 2014 [Page 23] Internet-Draft I2RS Arch June 2014 6.4.5.4.3. Object References Sometimes the relationship between objects is stronger. A valid ARP entry has to point to the active interface over which it was derived. This is the classic meaning of an object reference in programming. It can be used for relationships like containment or dependence. This is usually represented by an explicit modeling link. 6.4.5.4.4. Active Reference There is an even stronger form of coupling between objects if changes in one of the two objects are always to be reflected in the state of the other. For example, if a Tunnel has an MTU, and link MTU changes need to immediately propagate to the Tunnel MTU, then the tunnel is actively coupled to the link interface. This kind of active state coupling implies some sort of internal bookkeeping to ensure consistency, often conceptualized as a subscription model across objects. 7. I2RS Client Agent Interface 7.1. One Control and Data Exchange Protocol As agreed by the I2RS working group, this I2RS architecture assumes that there is a single I2RS protocol for control and data exchange; that protocol will be based on NETCONF[RFC6241] and RESTCONF [I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity and thereby enhances deployability. That protocol may need to use several underlying transports (TCP, SCTP, DCCP), with suitable authentication and integrity protection mechanisms. These different transports can support different types of communication (e.g. control, reading, notifications, and information collection) and different sets of data. Whatever transport is used for the data exchange, it must also support suitable congestion control mechanisms. The transports chosen should be operator and implementor friendly to ease adoption. 7.2. Communication Channels Multiple communication channels and multiple types of communication channels are required. There may be a range of requirements (e.g. confidentiality, reliability), and to support the scaling there may need to be channels originating from multiple sub-components of a routing element and/or to multiple parts of an I2RS client. All such communication channels will use the same higher level protocol. Use of additional channels for communication will be coordinated between the I2RS client and the I2RS agent. Atlas, et al. Expires December 25, 2014 [Page 24] Internet-Draft I2RS Arch June 2014 I2RS protocol communication can be delivered in-band via the routing system's data plane. I2RS protocol communication might be delivered out-of-band via a management interface. Depending on what operations are requested, it is possible for the I2RS protocol communication to cause the in-band communication channels to stop working; this could cause the I2RS agent to become unreachable across that communication channel. 7.3. Capability Negotiation The support for different protocol capabilities and I2RS Services will vary across I2RS Clients and Routing Elements supporting I2RS Agents. Since each I2RS Service is required to include a capability model (see Section 6.4), negotiation at the protocol level can be restricted to protocol specifics and which I2RS Services are supported. Capability negotiation (such as which transports are supported beyond the minimum required to implement) will clearly be necessary. It is important that such negotiations be kept simple and robust, as such mechanisms are often a source of difficulty in implementation and deployment. The protocol capability negotiation can be segmented into the basic version negotiation (required to ensure basic communication), and the more complex capability exchange which can take place within the base protocol mechanisms. In particular, the more complex protocol and mechanism negotiation can be addressed by defining information models for both the I2RS Agent and the I2RS Client. These information models can describe the various capability options. This can then represent and be used to communicate important information about the agent, and the capabilities thereof. 7.4. Identity and Security Role Each I2RS Client will have a unique identity; it can also have secondary identities to be used for troubleshooting. A secondary identity is merely a unique, opaque identifier that may be helpful in troubleshooting. Via authentication and authorization mechanisms based on the primary unique identity, the I2RS Client will have a specific scope for reading data, for writing data, and limitations on the resources that can be consumed. The scopes need to specify both the data and the value ranges. Atlas, et al. Expires December 25, 2014 [Page 25] Internet-Draft I2RS Arch June 2014 7.4.1. Client Redundancy I2RS must support client redundancy. At the simplest, this can be handled by having a primary and a backup network application that both use the same client identity and can successfully authenticate as such. Since I2RS does not require a continuous transport connection and supports multiple transport sessions, this can provide some basic redundancy. However, it does not address concerns for troubleshooting and accountability about knowing which network application is actually active. At a minimum, basic transport information about each connection and time can be logged with the identity. 7.5. Connectivity A client may or may not maintain an active communication channel with an agent. Therefore, an agent may need to open a communication channel to the client to communicate previously requested information. The lack of an active communication channel does not imply that the associated client is non-functional. When communication is required, the agent or client can open a new communication channel. State held by an agent that is owned by a client should not be removed or cleaned up when a client is no longer communicating - even if the agent cannot successfully open a new communication channel to the client. For many applications, it may be desirable to clean up state if a network application dies before removing the state it has created. Typically, this is dealt with in terms of network application redundancy. If stronger mechanisms are desired, mechanisms outside of I2RS may allow a supervisory network application to monitor I2RS clients, and based on policy known to the supervisor clean up state if applications die. More complex mechanism instantiated in the I2RS agent would add complications to the I2RS protocol and are thus left for future work. Some examples of such a mechanism include the following. In one option, the client could request state clean-up if a particular transport session is terminated. The second is to allow state expiration, expressed as a policy associated with the I2RS client's role. The state expiration could occur after there has been no successful communication channel to or from the I2RS client for the policy-specified duration. Atlas, et al. Expires December 25, 2014 [Page 26] Internet-Draft I2RS Arch June 2014 7.6. Notifications As with any policy system interacting with the network, the I2RS Client needs to be able to receive notifications of changes in network state. Notifications here refers to changes which are unanticipated, represent events outside the control of the systems (such as interface failures on controlled devices), or are sufficiently sparse as to be anomalous in some fashion. A notification may also be due to a regular event. Such events may be of interest to multiple I2RS Clients controlling data handled by an I2RS Agent, and to multiple other I2RS clients which are collecting information without exerting control. The architecture therefore requires that it be practical for I2RS Clients to register for a range of notifications, and for the I2RS Agents to send notifications to a number of Clients. The I2RS Client should be able to filter the specific notifications that will be received; the specific types of events and filtering operations can vary by information model and need to be specified as part of the information model. The I2RS information model needs to include representation of these events. As discussed earlier, the capability information in the model will allow I2RS clients to understand which events a given I2RS Agent is capable of generating. For performance and scaling by the I2RS client and general information privacy, an I2RS Client needs to be able to register for just the events it is interested in. It is also possible that I2RS might might provide a stream of notifications via a publish/subscribe mechanism that is not amenable to having the I2RS agent do the filtering. 7.7. Information collection One of the other important aspects of the I2RS is that it is intended to simplify collecting information about the state of network elements. This includes both getting a snapshot of a large amount of data about the current state of the network element, and subscribing to a feed of the ongoing changes to the set of data or a subset thereof. This is considered architecturally separate from notifications due to the differences in information rate and total volume. Atlas, et al. Expires December 25, 2014 [Page 27] Internet-Draft I2RS Arch June 2014 7.8. Multi-Headed Control As was described earlier, an I2RS Agent interacts with multiple I2RS Clients who are actively controlling the network element. From an architecture and design perspective, the assumption is that by means outside of this system the data to be manipulated within the network element is appropriately partitioned so that any given piece of information is only being manipulated by a single I2RS Client. Nonetheless, unexpected interactions happen and two (or more) I2RS clients may attempt to manipulate the same piece of data. This is considered an error case. This architecture does not attempt to determine what the right state of data should be when such a collision happens. Rather, the architecture mandates that there be decidable means by which I2RS Agents handle the collisions. The mechanism for ensuring predictability is to have a simple priority associated with each I2RS clients, and the highest priority change remains in effect. In the case of priority ties, the first client whose attribution is associated with the data will keep control. In order for this approach to multi-headed control to be useful for I2RS Clients, it is important that it be possible for an I2RS Client to register for changes to any changes made by I2RS to data that it may care about. This is included in the I2RS event mechanisms. This also needs to apply to changes made by CLI/NETCONF/SNMP within the write-scope of the I2RS Agent, as the same priority mechanism (even if it is "CLI always wins") applies there. The I2RS client may then respond to the situation as it sees fit. 7.9. Transactions In the interest of simplicity, the I2RS architecture does not include multi-message atomicity and rollback mechanisms. Rather, it includes a small range of error handling for a set of operations included in a single message. An I2RS Client may indicate one of the following three error handling for a given message with multiple operations which it sends to an I2RS Agent: Perform all or none: This traditional SNMP semantic indicates that other I2RS agent will keep enough state when handling a single message to roll back the operations within that message. Either all the operations will succeed, or none of them will be applied and an error message will report the single failure which caused them not to be applied. This is useful when there are, for example, mutual dependencies across operations in the message. Perform until error: In this case, the operations in the message are applied in the specified order. When an error occurs, no Atlas, et al. Expires December 25, 2014 [Page 28] - Destination address: copied from source address in received CLDT message. Further messages from the SEP belonging to the same TCAP transaction will now reach the same ASP. A.3.2. Connection-Oriented Transport Further messages for this connection are routed on DPC in the SS7 connection section (MTP routing label), and on IP address in the IP connection section (SCTP header). No other routing information is present in the SCCP or SUA messages themselves. Resources are kept within the SG to forward messages from one section to another and to populate the MTP routing label or SCTP header, based on the destination local reference of these messages (Connect Confirm, Data Transfer, etc.) This means that in the SG, two local references are allocated, one 3-byte value used for the SS7 section and one 4-byte value for the IP section. Also a resource containing the connection data for both sections is allocated, and either of the two local references can be used to retrieve this data e.g., for an incoming DT1 or CODT, for example. Authors' Addresses John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland EMail: john.Loughney@nokia.com Greg Sidebottom Signatus Technologies Kanata, Ontario Canada EMail: greg@signatustechnologies.com Loughney, et al. Standards Track [Page 129] RFC 3868 SUA October 2004 Lode Coene Siemens n.v. Atealaan 34 B-2200 Herentals Belgium Phone: +32-14-252081 EMail: lode.coene@siemens.com Gery Verwimp Siemens n.v. 34 Atealaan PO 2200 Herentals Belgium Phone: +32 14 25 3424 EMail: gery.verwimp@siemens.com Joe Keller Tekelec 5200 Paramount Parkway Morrisville, NC 27560 USA EMail: joe.keller@tekelec.com Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 Canada Phone: +1 780 490 1141 EMail: bidulock@openss7.org Loughney, et al. Standards Track [Page 130] RFC 3868 SUA October 2004 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. Loughney, et al. Standards Track [Page 131]