Draft Service Management Architecture June 1993 Service Management Architecture for Virtual Connection Services July 1, 1993 Frame Relay Service MIB (frnetmib) Working Group Kenneth R. Rodemann AT&T Bell Laboratories krr@qsun.att.com 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Rodemann Expires Jan 1, 1994 [Page 1] Draft Service Management Architecture June 1993 2. Abstract This document presents the Service Management Architecture, an architectural framework for defining SNMP MIB modules for Customer Network Management (CNM) of network services over connection-oriented networks. The work is motivated by the fundamental differences in management views and functionality between a service provider and a service customer. Differences between service provider and service customer include whole-network vs. network-portion view, direct vs. indirect management, and physical vs. logical view. These fundamental differences suggest a difference in philosophy between Service Management and Device Management. Much work has been done and experience gained in writing Device MIB modules for hands-on management of physical devices, but defining Service MIB modules is a relatively new area and requires the development of a new architectural framework. Rodemann Expires Jan 1, 1994 [Page 2] Draft Service Management Architecture June 1993 3. Introduction This document presents the Service Management Architecture, an architectural framework for defining SNMP MIB modules for Customer Network Management (CNM) of network services over shared networks. Network providers offer a myriad of network services, such as X.25, SMDS, Frame Relay, and ATM. Some of these provide connection-oriented service, while others provide connectionless service. CNM services are becoming an important extension of these transport services to provide customers with a management window into their portion of the shared service. This document focuses on an SNMP-based architectural framework for CNM of connection-oriented network services. The purpose of this work is to identify the notion of a Service MIB module, and to define an architectural framework for its definition that will permit easy extensibility and interoperability across various network services. In order to explore and understand how Service and Device management differ, consider the following fundamental differences in network management functionality between a network service provider and a service customer. First, service providers are responsible for managing the entire shared network as a whole, while service customers only view and manage their individual portions of the shared service. Because they have a restricted view of the network, customers are unable to perform certain network management functions in the shared environment. For example, a customer which sets routes for optimized throughput of their own traffic may disrupt another customer's traffic. Only the service provider, with a complete view of the entire network, is in a position to determine routes that allow provisioned access to network resources for all customers. A second fundamental difference in management functionality is that service providers manage the network internals directly, while customers manage their portion of the shared network indirectly. The service provider is responsible for the overall operation of the shared network, so any management control offered to customers must first be approved (perhaps manually) by the service provider before the control request takes effect in the network. Rodemann Expires Jan 1, 1994 [Page 3] Draft Service Management Architecture June 1993 Finally, while service providers see a physical view of the network, customers see a logical view. This logical view includes the customer's configuration of service access points (logical ports) and the virtual connections that run between these logical ports. The customer does not see the individual network switches along the paths of its virtual connections---setting up physical routes is a responsibility of the service provider. These fundamental differences in network management functionality suggest that there is a wholly different philosophy between Service Management and Device Management. A Device MIB module allows for hands-on management of a physical entity. A Service MIB module provides to customers a logical view of the customer's portion of a shared network service by modeling the service, not the underlying implementation or devices. Much work has been done and experience gained in writing Device MIB modules for hands-on management of physical devices, but defining Service MIB modules is a relatively new area and requires the development of a new architectural framework. Rodemann Expires Jan 1, 1994 [Page 4] Draft Service Management Architecture June 1993 4. Service Architecture A connection-oriented network service offered by a service provider can be viewed as a logical configuration of service access points (logical ports), access channels, and virtual connections (see Figure 1). Note that the term is used instead of 'interface' to distinguish between a service access point and a physical device access point. +---------------------+ | | ###@=====================@### |\ | | =================== | | \| | @### | /| | =================== | |/ | ###@=====================@### | | +---------------------+ Where @ is a service access point (logical port) ### is an access channel === is a virtual connection through the service provider's network Figure 1: Logical view of a connection-oriented network service, including service access points (logical ports), access channels, and virtual connections. The service provider manages the internals of the network (switch and trunk acquisition/placement, virtual connection provisioning/routing, internal fault detection/correction, etc.), so the service customer need not be concerned with such aspects. Instead, the service customer views and indirectly manages the components in its logical view of the service offering. Rodemann Expires Jan 1, 1994 [Page 5] Draft Service Management Architecture June 1993 A customer may subscribe to the services of more than one service provider, with end-to-end virtual connections that span multiple service providers' networks. These multi-segment virtual connections can be viewed as a concatenation of individual service-provider views (see Figure 2). +---------+ +---------+ +---------+ | Service | | Service | | Service | | Provider| | Provider| | Provider| ------+ | A | | B | | C | +------ | | | | | | | | Cust |###@=========@###@=========@###@=========@###| Cust | | | | | | | | ------+ | | | | | | +------ +---------+ +---------+ +---------+ Figure 2: Logical view of a customer's end-to-end virtual connection that spans across multiple service providers' networks. The end-to-end view is a concatenation of individual service-provider views. The next section discusses the Service Management Architecture, modeled upon the service architecture just presented. Rodemann Expires Jan 1, 1994 [Page 6] Draft Service Management Architecture June 1993 5. Service Management Architecture We previously discussed fundamental differences in network management functionality between a service provider and a service customer. These fundamental differences led to a distinction between a Device MIB module and a Service MIB module. A Service MIB module models the offered service, so we now apply the preceding Service Architecture to derive a generic Service MIB Module Architecture. There exist two views of virtual connections within the Service Architecture: service-provider views and customer end-to-end views. Service-provider views consist of single-segment virtual connections established through a single service provider's network. Customer end-to-end views consist of multi-segment end-to-end virtual connections that span across multiple service providers' networks. This end-to-end view represents a multi-segment virtual connection as a concatenation of individual service-provider segments. We first consider the service-provider view, then briefly outline the customer end-to-end view. 5.1 Service-Provider View The Service Architecture identifies three types of service objects within the service-provider view: service access points (logical ports), access channels, and virtual connections. A customer's logical configuration of service objects can be defined in generic terms, regardless of the underlying datalink protocol (X.25, Frame Relay, ATM, etc.) of the service offering. Defining the configuration in such a protocol-independent fashion will give to customers a consistent end-to-end view of interworking services. 5.1.1 Logical Port Table Structure This document follows the recommendations of the Internet Draft, "Evolution of the Interfaces Group of MIB-II" [1], which proposes that each layer in an interface's protocol stack have its own entry in the Interfaces Table, and the hierarchical relationships between interface layers are given in the new ifStack Table. Because the access channel is layered "below" the logical port, the logical port and the access channel each have their own ifTable entry and ifIndex. Rodemann Expires Jan 1, 1994 [Page 7] Draft Service Management Architecture June 1993 Consider the example given in Figure 3 of a typical Frame Relay interface stack. This interface stack is represented by two entries in the ifTable, one for the physical layer (DS1) and one for the Frame Relay layer. The ifStackTable gives the layering relationship between these two ifTable entries. Of course, there may be other layers involved; for example, a Frame Relay service may run over an ATM service, which itself runs over a physical layer. Note that since the Frame Relay service is modeled as a single entity, each logical port's ifIndex value is unique within the service provider's offering. Interfaces Table ================ ifIndex ifType +--------------------------------------------------------+ | : | | | | | : | | | | | 50 |......| XX (FR Network Service) | ....... | | : | | | | | 74 |......| 18 (DS1) | ....... | | : | | | | | : | | | | +--------------------------------------------------------+ ifStack Table ============= ifStackHigherLayer ifStackLowerLayer +--------------------------------------------+ | : | : | | 50 | 74 | | : | : | +--------------------------------------------+ Figure 3: Example Interfaces and ifStack Table entries for a Frame Relay Network Service over DS1. Rodemann Expires Jan 1, 1994 [Page 8] Draft Service Management Architecture June 1993 The ifTable contains entries for logical ports of various service protocols (for example, Frame Relay logical ports and ATM logical ports). Each of these network services are described in a protocol-specific MIB module that contains a logical port table indexed by the ifIndex of the associated ports. The ifSpecific variable of a logical port's Interfaces Table entry points to the associated protocol-specific logical port table. That table, in turn, may contain pointers to other protocol-specific tables, such as a link management table. There are a number of other ifTable variables that may apply to the network service logical port. When defining a protocol-specific MIB module, that module definition should define the proper use for each of these ifTable variables. Figure 4 shows an example table structure for a Frame Relay logical port. In the figure, the Interfaces Table entry for the port contains a pointer to the logical port's Frame Relay-specific table. This entry in turn contains a pointer to the proper link management MIB table for that logical port. 5.1.2 Virtual Connection Table Structure Virtual connections are logical data transport connections between a pair of logical ports. Within the Service Management Architecture, the MIB table structure for virtual connection tables is similar to the structure for logical ports. All virtual connections, regardless of protocol type, are placed in a protocol-independent VC table, and each entry in the VC table contains a pointer to the associated entry in a protocol-specific virtual connection table. Note that this pointer points to an actual *entry* in the protocol-specific table, not just the top of the table. This is necessary because the protocol-specific VC table may be indexed differently than the protocol-independent VC table. The protocol-independent VC table contains two entries for each virtual connection---one entry for each endpoint of the VC. Each endpoint is separately identified and indexed by a tuple (logical port ifIndex, VC id), where the VC id is a logical identifier unique to the associated logical port. This VC id is assigned by the service provider as it sees fit. The service provider *may* map the VC id directly to Rodemann Expires Jan 1, 1994 [Page 9] Draft Service Management Architecture June 1993 Frame Relay Interfaces Frame Relay link mgmt Table logical port table table +-----------------+ +-----------------+ +------------+ | ifIndex=50 | -->| portIndex=50 | -->| lmIndex=50 | |-----------------| | |-----------------| | |------------| | . | | | : | | | : | | : | | | : | | | : | |-----------------| | |-----------------| | +------------+ | ifType=XX | | | associated | | |(FR Network Srv) | | | link mgmt OID -+-- |-----------------| | |-----------------| | . | | | : | | : | | | : | |-----------------| | +-----------------+ | ifSpecific OID -+-- +-----------------+ Figure 4: Example Service Management Architecture table structure for a Frame Relay logical port. the addressing scheme used in the underlying protocol (e.g., DLCI for Frame Relay), but this is not necessary. The set of variables contained in a given row in the VC table describe the virtual connection's attributes as viewed from the endpoint identified by the row's indexing tuple (see Figure 5). To correlate the opposite endpoints of a given virtual connection, each endpoint row in the VC table references the other end's row via two variables that contain the remote end's logical port ifIndex and VC id. Variables associated with the remote end of a given table entry can be retrieved by indexing the VC table on the values of remote logical port ifIndex and remote VC id. Thus, the complete set of attributes for a virtual connection are contained in the aggregation of that connection's two table entries. Rodemann Expires Jan 1, 1994 [Page 10] Draft Service Management Architecture June 1993 +---------------------+ | | | | | | ingress ---> | | <---- ingress if1| VC1 VC1 |if2 ###@=====================@### egress <---- I | ----> egress | | | | | | | | +---------------------+ PROTOCOL-INDEPENDENT VIRTUAL CONNECTION TABLE (indexed on local ifIndex/local VC id) ============================================= local local remote remote ifIndex VC id ifIndex VC id In vars Out vars +---------------+---------------+---+-------+---+-------+ | 1 | 1 | 2 | 1 |...| |...| | | 2 | 1 | 1 | 1 |...| |...| | | : | : | | | | | | | +---------------+---------------+---+-------+---+-------+ Figure 5: Endpoint views for protocol-independent virtual connection table, and the associated table entries. Note that the protocol-independent virtual connection table described above does not yet exist as a part of MIB II. We therefore propose that a Virtual Connection Group defining a new table called vcTable be added to the ifMIBObjects MIB branch defined in [1]. Rodemann Expires Jan 1, 1994 [Page 11] Draft Service Management Architecture June 1993 This document proposes an initial set of objects for this table as follows: + local logical port ifIndex + local VC id + remote logical port ifIndex + remote VC id + VC status info + Ingress Octets + Ingress Packets + Egress Octets + Egress Packets + reference to (OID of) protocol-specific virtual connection MIB entry The vcTable contains an OID that points to associated entries in protocol-specific tables. To allow for management of interworking service objects, the reverse references must also be in place, i.e., references from the protocol-specific tables to entries in the vcTable. These backward references may be either OIDs or indexes into vcTable. Figure 6 shows how to use vcTable with an associated protocol-specific virtual connection table. proto-specific vcTable VC table +-----------------+ +------------+ | local ifIndex | -->| proto-spec | |-----------------| | | VC table | | local VC id | | | indexes | |-----------------| | |------------| | : | | | : | | : | | | : | |-----------------| | |------------| | proto-specific | | | vcTable | | VC entry OID -+-- | back ref | +-----------------+ +------------+ Figure 6: Service Management Architecture vcTable and associated protocol-specific virtual connection table relationship. Rodemann Expires Jan 1, 1994 [Page 12] Draft Service Management Architecture June 1993 5.1.3 Example The following shows an example scenario of the relationship between ifTable, vcTable, and their associated protocol-specific tables. The example also demonstrates how the Service Management Architecture provides a consistent management view of a service provider's interworking service. Figure 7 gives the configuration of a customer with 5 logical ports, 3 of which are Frame Relay logical ports (lp1, lp2, lp3) and 2 are ATM logical ports (lp4, lp5). Of the customer's 4 virtual connections, 2 are pure Frame Relay connections, 1 is a pure ATM connection, and 1 is an interworking connection between Frame Relay and ATM. The customer accesses the service via two different types of access channels, DS1 and DS3. +---------------------+ FR lp1| VC1 VC1 |lp2 FR DS1 ###@=====================@### DS1 |\ | | =================== | | VC2 VC1\|lp3 FR | @### DS3 | VC1 VC2/| | =================== | ATM lp4|/ |lp5 ATM DS3 ###@=====================@### DS3 | VC2 VC1 | +---------------------+ Figure 7: Example customer configuration of an interworking service offered by a service provider. lp is a logical port with ifIndex , and VC is a VC endpoint with VC id on the associated logical port. FR/ATM are the logical port-specific datalink protocols and DS1/DS3 are the specific physical layers. The ifTable has 5 interface stacks (one stack per logical port) associated with this service provider's network, as shown in Figure 8. The vcTable has 8 entries (one entry for each end of the 4 virtual connections), as shown in Figure 9. Rodemann Expires Jan 1, 1994 [Page 13] Draft Service Management Architecture June 1993 ifTable ======== ifIndex ifType ifSpecific +----------------------------------------------+ | 1 |...| XX (FR) |...| *FR Lport table | | 2 |...| XX (FR) |...| *FR Lport table | | 3 |...| XX (FR) |...| *FR Lport table | | 4 |...| YY (ATM) |...| *ATM Lport table | | 5 |...| YY (ATM) |...| *ATM Lport table | | 6 |...| 18 (DS1) |...| *DS1 table | | 7 |...| 18 (DS1) |...| *DS1 table | | 8 |...| 30 (DS3) |...| *DS3 table | | 9 |...| 30 (DS3) |...| *DS3 table | | 10 |...| 30 (DS3) |...| *DS3 table | +----------------------------------------------+ FR Logical Port Table ifStack Table ===================== ============= Lport Higher Lower ifIndex +---------------+ +------------------------+ | 1 | 6 | | 1 | ...... | | 2 | 7 | | 2 | ...... | | 3 | 8 | | 3 | ...... | | 4 | 9 | +------------------------+ | 5 | 10 | +---------------+ ATM Logical Port Table ====================== Lport ifIndex +------------------------+ | 4 | ...... | | 5 | ...... | +------------------------+ Figure 8: Application of Service Management Architecture (logical port-related tables) for the example. Rodemann Expires Jan 1, 1994 [Page 14] Draft Service Management Architecture June 1993 The example shows the forward and backward references between related tables. First, consider the references for the logical port-related tables. The forward reference (ifSpecific in ifTable) points to the top of the protocol-specific logical port table for the associated logical port. The protocol-specific logical port entry has the same index (ifIndex) as the ifTable entry. The backward reference for the logical port-related tables is implicit---the associated ifTable entry for a given protocol-specific entry is found by indexing the ifTable using the value of Lport ifIndex. Next, consider the references for the virtual connection-related tables. The forward reference within vcTable points to the actual entry within the proper protocol-specific VC table for the associated endpoint of the virtual connection. This reference must point to the actual entry, not the top, of the associated protocol-specific VC table because the protocol-specific VC table may be indexed differently than vcTable. For the backward references, the example shows two possible methods. The FR-specific VC table gives the vcTable's VC id, so the associated vcTable entry is found by indexing on (local ifIndex, vcTable VC id). The ATM-specific VC table gives an OID pointer back to the associated vcTable entry. Both protocol-specific VC tables also indicate if a virtual connection is an interworking connection---with a DLCI value of -1 for the Frame Relay module, and an interworking flag value of 1 for the ATM module. Finally, consider how to use these references to find the remote end of the interworking virtual connection. From the Frame Relay side: The index into the FR-specific VC table is (3, 200). The remote DLCI for this entry is -1, indicating that this is an interworking virtual connection. The backward reference uses the values of local ifIndex=3 and vcTable VC id=2, so indexing the vcTable on (3, 2), we find the remote end is remote ifIndex=4 and remote VC id=1 (4, 1). Now indexing the vcTable on (4, 1), we find that this entry points to the first entry in the ATM-specific table, which is the proper protocol-specific entry for the remote end of the virtual connection. Rodemann Expires Jan 1, 1994 [Page 15] Draft Service Management Architecture June 1993 vcTable (indexed on local ifIndex/local VC-id) ====================================== OID of table local local remote remote proto-specific entry ifIndex VC id ifIndex VC id VC table +-----------------------------------------------------+ 1 | 1 | 1 | 2 | 1 |...| *FR VC entry 1 | 2 | 1 | 2 | 3 | 1 |...| *FR VC entry 2 | 3 | 2 | 1 | 1 | 1 |...| *FR VC entry 3 | 4 | 3 | 1 | 1 | 2 |...| *FR VC entry 4 | 5 | 3 | 2 | 4 | 1 |...| *FR VC entry 5 | 6 | 4 | 1 | 3 | 2 |...| *ATM VC entry 1 | 7 | 4 | 2 | 5 | 1 |...| *ATM VC entry 2 | 8 | 5 | 1 | 4 | 2 |...| *ATM VC entry 3 | +-----------------------------------------------------+ FR-SPECIFIC VC TABLE (indexed on local ifIndex/local DLCI) ===================================== table local local vcTable remote remote entry ifIndex DLCI VC id ifIndex DLCI +--------------------------------------+ 1 | 1 | 100 | 1 | 2 | 200 | 2 | 1 | 110 | 2 | 3 | 110 | 3 | 2 | 200 | 1 | 1 | 100 | 4 | 3 | 110 | 1 | 1 | 110 | 5 | 3 | 200 | 2 | 4 | -1 | +--------------------------------------+ ATM-SPECIFIC VC TABLE (indexed on local ifIndex/local VPI/local VCI) ============================================== OID of table local local local vcTable I/W remote remote remote entry ifIndex VPI VCI entry flag ifIndex VPI VCI ----------------------------------------------------+ 1 | 4 | 100 | 10 | *entry 6 | 1 | 3 | 0 | 0 | 2 | 4 | 110 | 10 | *entry 7 | 0 | 5 | 100 | 20 | 3 | 5 | 100 | 20 | *entry 8 | 0 | 4 | 110 | 10 | ----------------------------------------------------+ Figure 9: Application of Service Management Architecture (virtual connection-related tables) for the example. Rodemann Expires Jan 1, 1994 [Page 16] Draft Service Management Architecture June 1993 From the ATM side: The index into the ATM-specific VC table is (4, 100, 10). The I/W flag for this entry is 1, indicating that this is an interworking virtual connection. The backward-reference OID for this entry points to the sixth entry in vcTable. We find the remote end for the sixth vcTable entry is remote ifIndex=3 and remote VC id=2 (3, 2). Now indexing the vcTable on (3, 2), we find that this entry points to the fifth entry in the FR-specific table, which is the proper protocol-specific entry for the remote end of the virtual connection. 5.2 Customer End-to-end View The customer end-to-end view provides the correlating information to view end-to-end virtual connections that span through multiple service providers' networks. This end-to-end view represents a multi-segment virtual connection as a concatenation of individual service-provider segments. The section of the Service Management Architecture is very sketchy. An adequate definition of this view requires much more discussion and experience. Here is a sketchy initial stab at the information needed for this end-to-end view. This is not in MIB format, i.e., having a table within a table, but this shows the type of required information for this view. An entry in the end-to-end MIB module may include: + end-to-end VC id + end-to-end VC status info + ordered list of VC Segments: - VC Segment number - VC Segment Provider info - VC Segment status info - point A logical port ifIndex - point A VC id - point B logical port ifIndex - point B VC id Note the use of generic terms "point A" and "point B". The intent is to refrain from using terms like Originating/Terminating and Source/Destination that suggest a master-slave type of relationship. The only relationship Rodemann Expires Jan 1, 1994 [Page 17] Draft Service Management Architecture June 1993 to be inferred from the terms point A and point B is the polarization or orientation of individual VC segments, i.e., point B of the i'th segment is attached to point A of the i+1'st segment. Rodemann Expires Jan 1, 1994 [Page 18] Draft Service Management Architecture June 1993 6. Summary This document presents the Service Management Architecture for defining Service MIB modules. The work is motivated by the fundamental differences in management views and functionality between a service provider and a service customer. Differences between service provider and service customer include whole-network vs. network-portion view, direct vs. indirect management, and physical vs. logical view. These fundamental differences suggest a difference in philosophy between Service Management and Device Management. The Service Architecture models a customer's view of a shared network service as a logical configuration of logical ports, access channels, and virtual connections. A service customer indirectly manages the components within its logical view, not the internals of the shared network. Virtual connections that span across multiple service providers' networks are viewed as concatenations of individual service-provider segments. Modeled upon the Service architecture, the Service Management Architecture presents two views of virtual connections: service-provider views and customer end-to-end views. Service-provider views consist of single-segment virtual connections established through a single service provider's network, while customer end-to-end views consist of multi-segment end-to-end virtual connections that span across multiple service providers' networks. This document discusses more of the service-provider view than it does the customer end-to-end view. The service-provider view consists of ifTable and a new vcTable for defining configuration, with references to protocol-specific MIB modules. This structure provides a clean Service Management Architecture that promotes consistent views across various underlying implementations and interworking of services. Rodemann Expires Jan 1, 1994 [Page 19] Draft Service Management Architecture June 1993 7. References [1] McCloghrie, K., F. J. Kastenholz, "Evolution of the Interfaces Group of MIB-II", Internet Draft, Interfaces MIB Working Group, 1 June 1993. Rodemann Expires Jan 1, 1994 [Page 20] Draft Service Management Architecture June 1993 8. Security Considerations Security issues are not discussed in this memo. 9. Author's Address Kenneth R. Rodemann AT&T Bell Laboratories Room 1F-435A 101 Crawfords Corner Road PO Box 3030 Holmdel, NJ 07733-3030 908-949-6229 krr@qsun.att.com Rodemann Expires Jan 1, 1994 [Page 21] Table of Contents 1. Status of this Memo................................. 1 2. Abstract............................................ 2 3. Introduction........................................ 3 4. Service Architecture................................ 5 5. Service Management Architecture..................... 7 5.1 Service-Provider View.......................... 7 5.1.1 Logical Port Table Structure 7 5.1.2 Virtual Connection Table Structure 9 5.1.3 Example 13 5.2 Customer End-to-end View....................... 17 6. Summary............................................. 19 7. References.......................................... 20 8. Security Considerations............................. 21 9. Author's Address.................................... 21 Rodemann Expires Jan 1, 1994 [Page 22]