idnits 2.17.1 draft-ietf-gsmp-msf-response-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1987 (ref. '1') == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-00 -- No information found for draft-doria-gsmp-arm - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GSMP Working Group Kenneth Sundell 2 Internet-Draft Nortel Networks 3 Avri Doria 4 Expiration Date: Feb 20, 2000 Nokia 5 20 August, 1999 7 GSMP WG response to MSF SCI Requirements 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at: 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed 30 at: http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). All Rights 37 Reserved. 39 Abstract 41 This document is the IETF GSMP Working Group response to "Service 42 Control Interface Requirements" submitted by the Multiservice 43 Switching Forum Switch Control Working Group as . This document compares the capabilities of the 45 GSMPv3 against the MSF SCI requirements. It also invites 47 INTERNET-DRAFT..GSMP WG response to MSF SCI Requirements 20.08.99 48 contributions from individuals of MSF on meeting any unresolved 49 requirements. 51 1. Introduction 53 The Multiservice Switching Forum (MSF) is a body dedicated to 54 arriving at implementation agreements that satisfy the needs of 55 carriers offering multiservice networks. MSF has, by its liaison, 56 submitted a set of requirements on a switch control interface stated 57 in [5] to the GSMP working group. The reason for the liaison is that 58 the MSF has decided to use GSMPv3 as their base switch control 59 protocol and now wants to be sure that their original requirements 60 will be supported by GSMP. During the 45th IETF meeting in Oslo a 61 consensus was reached on the notion that support of the requirements 62 was definitely within the GSMP WG interest, and that the WG supported 63 this goal. 65 This documents compares the capabilities of the GSMPv3 [3] against 66 the MSF SCI requirements stated in [5]. Four different ratings are 67 used to give a rough understanding of the level of conformance. 69 S: requirement believed to be satisfied 71 PS: requirement believed to be partially satisfied 73 NS: requirement believed not to be satisfied 75 E: requirement needs further explanation 77 PE: requirement is pending (e.g. waiting for GSMP working Group 78 action or IESG resolution) 80 One objective of this document is to request further explanations on 81 requirements that were not adequately understood. It also requests 82 MSF contributions, in the form of either I-Ds or WG mail list 83 discussions, on ways to resolve issues in the categories `PS', `NS' 84 and `E' in the list above. This document has been reviewed on the 85 GSMP WG mailing list for rough consensus before being presented to 86 the MSF body as an MSF contribution. 88 2. Terminology 89 SCI: Switch Control Interface. The interface used between a 90 VSC (SCI Master) and a VS (SCI Slave). 92 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 93 SCP: Switch Control Protocol. SCP is the protocol that 94 realises 95 the SCI. 97 VS: Virtual Switch. VS is an arbitrary subset of switch 98 resources that can be controlled as a unit through a 99 single 100 SCI slave. The switch resources that make up a Virtual 101 Switch can come from a single switch, or a group of 102 physically connected switches. 104 VSCE: Virtual Switch Controller Entity. VSCE is an active 105 software/hardware entity that implements all or part of 106 an SCI master and exerts control over a VS by 107 communicating with its SCI Slave. 109 VSC: Virtual Switch Controller. VSC is A set of one or more 110 VSCE, which together control the resources of a VS. A 111 VSC implements the Switching and Bearer Control Function 112 for a given service. 114 3. Switch Control Interface Requirements 116 This section lists the MSF requirements in the same order as in [4]. 117 The believed level of conformance to GSMPv3 is stated as defined in 118 the introduction section of this document. 120 3.1 Fundamental Requirements 122 The SCI shall allow the control of ATM switching and adaptation 123 functions for the following services over an ATM capable core: 125 Requirement #66: Support for ATM service 127 GSMPv3 compliance: S. requirement believed to be satisfied. 128 The requirement was already supported in GSMPv2 129 and will be retained in GSMPv3. 131 Requirement #67: Support for Frame Relay service 133 GSMPv3 compliance: PS. requirement believed to be partially 134 satisfied. 135 The GSMP WG charter includes support for frame 136 relay switches. So far only frame relay 137 services are identified. Contributions are 139 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 140 needed for describing what is needed for 141 supporting frame relay switches as well as for 142 allowing the control of ATM switching and 143 adaptation functions for frame relay services 144 over an ATM capable core. 146 It should be noted that GSMPv3 does not include 147 support for translating (adapting) from Frame 148 Relay to ATM label types or support for 149 translating from frames to cells. It is also 150 not clear whether such capabilities are 151 considered with the scope of GSMP or whether 152 they belong to another protocol mechanism, for 153 example either a network or policy management 154 mechanism. 156 Requirement #68: Support for Circuit Emulation Service 158 GSMPv3 compliance: NS. requirement believed not to be satisfied. 159 E. requirement needs further explanation 160 CE Service is not supported in GSMPv3. There is 161 also a need for further specification of this 162 requirement, as the WG did not have a clear 163 idea of the requirements for supporting circuit 164 emulation services. 166 Requirement #69: Support for MPLS service 168 GSMPv3 compliance: S. requirement believed to be satisfied. 169 See ref. [3]. Support for MPLS services is the 170 primary chartered requirement for the GSMP 171 working group and as such is an ongoing focus 172 for the WG. 174 3.2 Switch Partitioning Requirements 176 The SCI shall allow separate VSCs to control the VSs of a partitioned 177 MSS switch. 179 Requirement #4: partition a MSS into multiple VSs 181 GSMPv3 compliance: S. requirement believed to be satisfied. 182 The partition identifier was introduced in 183 draft-ietf-gsmp-00.txt in order to support 184 partitioning. The partitioning function itself, 185 however, is not considered to be part of GSMP. 187 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 188 Requirement #17: static/deterministic partitioning 190 GSMPv3 compliance: S. requirement believed to be satisfied. 191 Static partitioning is supported in [3]; i.e. 192 the partition has to be done before running 193 GSMP. 195 Requirement #18: dynamic/statistical partitioning 197 GSMPv3 compliance: PS. requirement believed to be partially 198 supported. 199 While physical resources can be statistical 200 shared among partitions, there is no support 201 for dynamic partitioning. 203 Requirement #19: The controller sees and controls its own 204 resources 206 GSMPv3 compliance: S. requirement believed to be satisfied. 207 The partition identifier was introduced in 208 draft-ietf-gsmp-00.txt. It is a requirement 209 that a partition's resources be available only 210 to that partition's VSC. 212 3.3 Resource and Service Model Requirements 214 Requirement #73: MSF switches and thus the SCI shall support an 215 ATM Forum Switch Service Abstraction 217 GSMPv3 compliance: S. requirement believed to be satisfied. 218 See [3]. 220 Requirement #74: MSF switches and thus the SCI shall support 221 an MPLS Switch Service Abstraction 223 GSMPv3 compliance: S. requirement believed to be satisfied. 224 See [3]. 226 Requirement #75: MSF switches and thus the SCI shall support the 227 IEEE P1520 (PIN) Switch Service Abstraction 229 GSMPv3 compliance: S. requirement believed to be satisfied. 230 The switch service abstraction model specified 231 in [6] is allowed for usage in GSMP, though it 232 will not be part of the GSMPv3 specification. 233 See chapter 2.1 "Changes to the system 234 configuration request message" in [4], which 236 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 237 will part of the next revision of [3] 238 A suggestion has been made that GSMPv3 should 239 include this abstraction in the base protocol. 240 This would need to be recommended formally to 241 the WG, and then discussed at the next IETF 242 meeting. It is the co-authors' opinion, 243 however, that the requirement is satisfied by 244 including support for the IEEE Service model as 245 an optional extension. 247 Requirement #76: MSF switches and thus the SCI shall support a 248 Switch Resource Abstraction 250 GSMPv3 compliance: S. requirement believed to be satisfied. 251 The optional Abstract and Resource Model [4] 252 was approved at the Oslo meeting and will be 253 part of an updated version of [3]. This 254 mechanism allows for a partition to negotiate 255 the use of a resource abstraction. Currently 256 there are two such abstractions available:, the 257 abstraction defined by qGSMP and the 258 abstraction defined in Chapter 9 of GSMPv2 [2]. 259 A suggestion has been made that GSMPv3 should 260 include this resource model in the base 261 protocol. This would need to be recommended 262 formally to the WG, and then discussed at the 263 next meeting. It is the co-authors' opinion, 264 however, that the requirement is satisfied by 265 including support for the IEEE resource model 266 as an optional extension. 268 Requirement #78: The SCI shall allow the VSC to discover the 269 switch 270 resource abstraction supported by the VS 272 GSMPv3 compliance: S. requirement believed to be satisfied. 273 The Abstract and Resource Option negotiation 274 mechanism contained in [4] was approved at the 275 Oslo meeting and will be part of the updated 276 version of [3]. 278 Requirement #79: The SCI shall be extensible to allow new 279 service 280 and resource abstractions. 282 GSMPv3 compliance: S. requirement believed to be satisfied. 283 The [4] was approved at the Oslo meeting and 284 will be part of the updated version of [3]. 286 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 287 Requirement #21: The SCI shall not prevent over-subscription of 288 resources, such as bandwidth. 290 GSMPv3 compliance: S. requirement believed to be satisfied. 291 Over-subscription of resources is not 292 prevented, though there are no provisions to 293 specifically support and track over- 294 subscription of resources. 296 3.4 Architectural Requirements 298 Requirement #80: The SCI shall provide a standard mechanism for 299 inclusion of vendor-proprietary extensions 301 GSMPv3 compliance: PS. requirement believed to be partially 302 supported. 303 GSMP today allows proprietary extensions in the 304 end of the message, that is, everything after 305 the last "GSMP message field" is considered as 306 available for proprietary information. There is 307 a question on whether this is enough or whether 308 an extra field that flags for additional 309 information such as records, objects or TLV's 310 should be included. Opinions and contributions 311 are invited on this issue. 313 Requirement #1: A VS shall be controlled by only one VSC at any 314 given time. 316 GSMPv3 compliance: S. requirement believed to be satisfied. 317 A partition identifier is included in [3] and 318 GSMP only allows a single VSC to control a 319 switch partition. 321 Requirement #2: A VSC can be composed of an arbitrary number of 322 VSCEs and a VS can be composed of the resources 323 of an arbitrary number of physical switches. 325 GSMPv3 compliance: S. requirement believed to be satisfied. 326 The partition identifier will not limit the 327 number of physical elements within either the 328 VS or the VSC. The protocol, does, however, 329 require that there be only one control channel 330 between the VSC and the VS. 332 Requirement #5: The SCI shall be able to support a VSC that is 333 composed of multiple active VSCEs, all of which 335 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 336 can issue SCI requests simultaneously to the 337 same VS. The VS is not responsible for co- 338 ordination of the VSCEs. 340 GSMPv3 compliance: NS. requirement believed not to be satisfied. 341 There is currently no support for redundant 342 controllers in [3]. In order to fulfil this 343 requirement proposals are needed. 345 Requirement #6: It shall be possible for the VSCEs that make up 346 aVSC to run on physically separate platforms and 347 to 348 access the VS over separate physical paths 349 (links). 351 GSMPv3 compliance: NS. requirement believed not to be satisfied. 352 There is currently no support for multiple 353 control channels in [3]. In order to fulfil 354 this requirement proposals are needed. 356 Requirement #55: The SCI may support redundant physical 357 connectivity between a VSCE and a VS. 359 GSMPv3 compliance: NS. requirement believed not to be satisfied. 360 There is currently no support for redundant 361 controllers in [3]. In order to fulfil this 362 requirement proposals are needed. 364 Requirement #57: The SCI should not be the limiting constraint 365 on 366 the number of connections concurrently active 367 on a switch. 369 GSMPv3 compliance: S. requirement believed to be satisfied. 370 The GSMPv3 does not impose a limiting 371 constraint. 373 Requirement #58: The SCI should not restrict the number of 374 virtual 375 ports. 377 GSMPv3 compliance: S. requirement believed to be satisfied. 378 The GSMPv3 does not include any restrictions on 379 the number of ports other then restriction by 380 virtue of field size. 382 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 383 Requirement #59: The SCI shall not restrict the physical 384 interface 385 types supported by the switch. 387 GSMPv3 compliance: S. requirement believed to be satisfied. 388 The GSMPv3 does not include any restrictions on 389 physical interface types, though only a limited 390 number of types are currently defined. 392 Requirement #60: The SCI shall allow support for at least one 393 terabit/second throughput per virtual port. The 394 SCI encoding of bandwidth values shall be 395 extensible, and shall include those specified 396 by ATM Forum. 398 GSMPv3 compliance: S. requirement believed to be satisfied. 399 No restrictions are identified in [3]. 401 Requirement #61: The SCI shall allow a VSC to have multiple 402 outstanding requests (e.g., to support high 403 call rates). 405 GSMPv3 compliance: S. requirement believed to be satisfied. 406 Outstanding request messages are associated 407 with the corresponding response messages by a 408 transaction identifier. This allows for 409 support of multiple request messages. 411 3.5 Fault Tolerance and Synchronization Requirements 413 Requirement 8#: The SCI shall not restrict the switch 414 redundancy 415 scheme and must allow for m:n hardware level 416 redundancy in the switch (e.g., Card level 417 redundancy, other component level switching, 418 APS on interfaces). 420 GSMPv3 compliance: PS. requirement believed to be partially 421 satisfied. 422 E. requirement needs further explanation. 423 There are no mechanisms in GSMPv3, which 424 restrict hardware level redundancy. There are 425 also no mechanisms, which support such 426 redundancy. This requirement needs further 427 clarification in order to understand whether 429 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 430 such a passive lack of restrictions meets the 431 requirement. 433 Requirement #9: The SCI shall provide a mechanism for detecting 434 loss of synchronization of state (consistency 435 of state between VSC and VS). The mechanism 436 must be able to detect whether or not the 437 switch has the same configuration (including 438 connections, connection configuration 439 parameters and switch configuration parameters) 440 that the VSC has sent into it. 442 GSMPv3 compliance: S. requirement believed to be satisfied. 443 This is currently done by checking on the state 444 of each connection. Recommendations for better 445 mechanisms are invited. 447 Requirement #10: In order to be scalable, the SCI must provide a 448 recovery mechanism that does not disrupt 449 unaffected connections. The recovery mechanism 450 must be able to resynchronize only the part of 451 the state that is related to the failure 453 GSMPv3 compliance: PS. requirement believed to be partially 454 satisfied 455 While non-disruptive recovery is supported, the 456 recovery might not be fast enough for specific 457 configurations, e.g. switches with a large 458 number of ports. The GSMP utilises port by port 459 recovery. Recommendations for better mechanisms 460 are invited. 462 Requirement #11: The SCI shall support hitless redundant VSCE 463 switchover: A redundant VSCE should be able to 464 assume control of the VS without disrupting 465 existing user plane connections. 467 GSMPv3 compliance: S. requirement believed to be satisfied. 468 The adjacency mechanism includes a flag, which 469 indicates that prior state should be retained 470 even though a new adjacency has been 471 established. 473 Requirement #12: The SCI should be able to operate properly over 474 an 475 unreliable interconnect or network. 477 GSMPv3 compliance: S. requirement believed to be satisfied. 478 See 2.3 "TCP/IP Encapsulation" in [3]. 480 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 481 Additionally, mechanisms are provided which 482 require optional acknowledgement of every 483 command. 485 Requirement #64: The SCI shall support hitless resynchronization 486 between the VSC and the VS when they are 487 already in sync. Some examples of 488 resynchronization when the VSC and VS are in 489 sync are: 491 - Resynchronization after VSC rebuild 493 - Resynchronization after VSC 494 upgrades/downgrades 496 - Resynchronization after switch component 497 switchover 499 - Resynchronization after switch component 500 rebuild 502 - Resynchronization after switch component 503 upgrade/downgrade 505 GSMPv3 compliance: E. requirement needs further explanation. 506 In order to understand the requirement examples 507 should be provided by MSF. While GSMP doesn't 508 prevent such activities, it doesn't support 509 explicitly them either. 511 Requirement #65: The VSC shall be allowed to submit new SCI 512 requests which affect VS state 513 (e.g., establish new connections, delete 514 existing connections) while resynchronization 515 is being performed, after re-establishment of 516 the association between the VSC and the VS. 518 GSMPv3 compliance: S. requirement believed to be satisfied. 519 GSMP requires resynchronization in two steps. 520 While step 1, adjacency, is being taken care 521 of, no commands are accepted. After adjacency 522 any command is accepted, even if state 523 coherency is being checked at the time. 525 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 526 3.6 Security Requirements 528 Requirement #13: The SCI shall allow the VSC and VS to 529 authenticate 530 each other's identity using a standard 531 authentication protocol (e.g., IPSec, ATM 532 Forum) 534 GSMPv3 compliance: PE. requirement is pending. 535 The level of security is a subject for 536 discussion in several IETF working groups. The 537 issue has been addressed to the IESG to be 538 resolved. A mechanism has been suggested within 539 the group that may not be adequate for IETF 540 security purposes. It is possible that use if 541 IPSec will be mandated for security purposes 542 when using the IP encapsulation. 543 In terms of the ATM Encapsulation, the security 544 mechanism reportedly is taken care of during 545 connection establishment of the control 546 channel, so there should be no change required 547 to GSMP to support ATM security. 549 Requirement #14: The SCI shall allow for secure communication 550 between VSC and VS using a standards based 551 security protocol 553 GSMPv3 compliance: PE. requirement believed to be satisfied. 554 The level of security is a subject for 555 discussion in several IETF working groups. The 556 issue is addressed to the IESG to be resolved. 557 A mechanism has been suggested with the group 558 that may not be adequate for IETF security 559 purposes. It is possible that use if IPSec 560 will be mandated for security purposes when 561 using the IP encapsulation. 562 In terms of the ATM Encapsulation, the security 563 mechanism reportedly is taken care of during 564 connection establishement of the control 565 channel, so there should be no change required 566 to GSMP to support ATM security. 568 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 569 3.7 Functional Requirements 571 3.7.1 Virtual Switch Configuration and Management 573 Requirement #20: The SCI shall allow the VS to display its 574 resources to a VSC in a generic way. 576 GSMPv3 compliance: S. requirement believed to be satisfied. 577 See chapter 7 "Configuration message" in [3]. 579 Requirement #25: The SCI shall allow the VSC to discover the VS 580 capabilities in a generic way. 582 GSMPv3 compliance: S. requirement believed to be satisfied. 583 See chapter 7 "Configuration message" in [3]. 585 3.7.2 Connection Control 587 Requirement #32: The SCI shall allow the VSC to add, delete, and 588 verify connections within its VS. 590 GSMPv3 compliance: S. requirement believed to be satisfied. 591 See chapter 4 "Connection Management Messages" 592 in [3]. 594 Requirement #33: The SCI shall allow the VSC to modify 595 connections 596 within its VS. 598 GSMPv3 compliance: S. requirement believed to be satisfied. 599 See chapter 4 "Connection Management Messages" 600 in [3]. 602 Requirement #34: The SCI shall support point to point 603 connections. 605 GSMPv3 compliance: S. requirement believed to be satisfied. 606 See chapter 4 "Connection Management Messages" 607 in [3]. 609 Requirement #35: The SCI shall support point to multipoint 610 connections. 612 GSMPv3 compliance: S. requirement believed to be satisfied. 613 See chapter 4 "Connection Management Messages" 614 in [3]. 616 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 617 Requirement #36: The SCI shall support multipoint to point 618 connections. 620 GSMPv3 compliance: S. requirement believed to be satisfied. 621 See chapter 4 "Connection Management Messages" 622 in [3]. 624 Requirement #38: The SCI shall support virtual channel and 625 virtual 626 path connections. 628 GSMPv3 compliance: S. requirement believed to be satisfied. 629 See chapter 4 "Connection Management Messages" 630 in [3]. 632 Requirement #39: The SCI shall support the termination of 633 virtual 634 paths (splitting a VP into VCs) as per I.311. 636 GSMPv3 compliance: S. requirement believed to be satisfied. 637 Since gsmp is not directly involved in any ATM 638 signaling issues there is only the cell 639 switching to consider. GSMP supports VPC 640 termination in exactly the same way that it 641 supports cell switching on the VPI/VCI. GSMP 642 makes no distinction here. 643 For example, lets take a simple scenario, using 644 a terminology of (port:vpi:vci->port:vpi:vci) 645 to represent GSMP branches. Now, let's add the 646 following: 647 (2:0:40->5:20:1) and (5:20:1->2:0:40) 648 (7:0:51->5:20:2) and (5:20:2->7:0:51) 649 (8:0:77->5:20:3) and (5:20:3->8:0:77) 650 at the switch adjacent to this one's port 5, we 651 then switch the VPI=20 as a VPC, e.g. we add 652 VPC branches (5:20:*->12:18:*) and (12:18:*- 653 >5:20:*). As far as cell switching is concerned 654 we have terminated the VPC. From GSMP's point 655 of view, VPC termination is no different from 656 VCC switching. So while VPC termination is not 657 explicit in the protocol, it is supported. 659 Requirement #41: The SCI shall allow the VSC to specify traffic 660 and 661 QoS parameters for each connection. 663 GSMPv3 compliance: S. requirement believed to be satisfied. 664 See chapter 9 "Service Model Definition" in [3]. 666 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 667 3.7.3 Exception Notification 669 Requirement #49: The SCI should contain the vocabulary for the 670 switch to notify VSCs of asynchronous events 671 occurring in the switch that affect their VS. 672 The minimal set of traps is: 674 - Interface up of down 676 - Change in available interfaces 678 - Interface faults 680 - Switching faults 682 GSMPv3 compliance: S. requirement believed to be satisfied. 683 See chapter 8 "Event Messages" in [3]. 685 Requirement #50: The SCI shall provide a flow control mechanism 686 for 687 asynchronous event notifications. 689 GSMPv3 compliance: S. requirement believed to be satisfied. 690 In [3] an event flag is used for each type of 691 event messages corresponding to a switch port. 692 Event flags together with an event sequence 693 number, forms a simple flow control scheme 694 preventing the switch from flooding the 695 controller with event messages. 696 See chapter 8 "Event Messages" [3]. 697 Suggestions for other mechanisms are invited. 699 Requirement #51: The SCI shall provide a mechanism for filtering 700 asynchronous event notifications. 702 GSMPv3 compliance: S. requirement believed to be satisfied. 703 See chapter 5 "Port Management messages" in [3]. 704 Suggestions for other mechanisms are invited. 706 3.8 SCI Protocol Implementation Requirements 708 Requirement #52: The SCP shall be capable of operating over ATM 710 GSMPv3 compliance: S. requirement believed to be satisfied. 711 See chapter 2.1 "ATM encapsulation" in [3] 713 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 714 Requirement #54: The SCP shall be capable of operation over IP. 716 GSMPv3 compliance: S. requirement believed to be satisfied. 717 See chapter 2.3 "TCP/IP Encapsulations" in [3]. 719 Requirement #56: The SCP should work as a remote protocol. 721 GSMPv3 compliance: S. requirement believed to be satisfied. 722 It is not noted explicitly in [3] but GSMP may 723 be used remotely. 725 3.9 Management Requirements 727 The management requirements are not considered as MSF SCI 728 requirements. The MSF Switch Control working group has not yet agreed 729 upon which of these requirements do indeed apply to the SCI and 730 intends to clarify these requirements in a future I-D. The compliance 731 check to these requirements will be done in a future revision of this 732 draft when the results from MSF have been received. 734 The GSMP group is, however, chartered to produce a GSMP MIB. Some of 735 these requirements may be met within such a MIB. Alternatively, 736 future GSMP work not currently chartered may include work towards 737 dynamic policy management of a switch's resources. It is possible 738 that some of these management requirements may fit into such work 739 once it has been defined and approved by the IESG. 741 In any case, all of the management requirements need further 742 definition and explication. 744 3.9.1 Resource and Service Model Requirements 746 Requirement #22: The SCI shall allow the VSC to associate 747 subsets of the resources assigned its VS to 748 service classes offered by the VS. 750 Requirement #77: The management interface for creating VSs shall 751 allow the user to choose from a set of offered 752 switch resource abstractions. 754 3.9.2 Virtual Switch Configuration and Management 756 Requirement #26: The SCI shall allow the VSC to read and write 757 VS 758 configuration parameters. 760 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 761 Examples include: 763 - Assigning bandwidth to classes of service 765 - Setting flow control parameters for the SCI 767 3.9.3 Virtual Port Configuration and Management 769 Requirement #27: The SCI shall allow a virtual port to be 770 brought 771 in to service or taken out of service. 773 Requirement #28: The SCI shall allow the VSC to reset a virtual 774 port that belongs to its VS. 776 Requirement #29: The SCI shall allow the VSC to configure 777 rudimentary test states. 779 Requirement #30: The SCI shall allow the VSC to set the 780 bandwidth 781 of a virtual port. 783 Requirement #31: The SCI may allow the VSC to establish and 784 manipulate label ranges per virtual port. 786 3.9.4 State and Statistics Reporting 788 Requirement #42: The SCI shall allow the VSC to read counters 789 associated with VS input and output virtual 790 ports. 792 Requirement #43: The SCI shall allow the VSC to read counters 793 associated with virtual path and virtual 794 channel connections. 796 Requirement #44: The SCI shall allow the VSC to read individual 797 switched connection state. Connection states 798 include following: does-not-exist, exists, 799 exists-failed. 801 Requirement #45: The SCI shall allow the VSC to perform bulk 802 reads 803 of statistics for all connections on a 805 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 806 specified virtual path or a specified virtual 807 port. 809 Requirement #46: The SCI may allow the VSC to collect data for 810 performance monitoring, account management, and 811 other statistics on request or at present 812 intervals. 814 Requirement #47: The SCI shall allow the VSC to collect 815 statistics 816 for a single connection or for groups of 817 connections for efficient scaling. 819 Requirement #48: The detailed list of required statistics should 820 include the BICI statistics for ATM and other 821 statistics types for other services. 823 4. Conclusion 825 It seems that the majority of the requirements are already supported 826 by the work done in [1] and [2] together with the efforts done in the 827 GSMP working group in producing GSMPv3[3]. There are, however, still 828 some requirements that not met or are only partially by what is 829 currently included in GSMPv3. The GSMP WG encourages contributors to 830 fill these holes in order to get them into an updated version of 831 GSMPv3[3]. The most effective way of doing this is by submitting I- 832 D's or using the GSMP mailing list for the purpose. 834 Requirements believed to be satisfied: 835 66, 69, 4, 17, 19, 73, 74, 75, 76, 78, 79, 21, 1, 2, 57, 58, 59, 60, 836 61, 9, 11, 12, 65, 20, 25, 32, 33, 34, 35, 36, 38, 39, 41, 49, 50, 837 51, 54, 56 839 Requirements believed to be partially satisfied: 840 67, 18, 80, 8, 10 842 Requirements not believed to be supported: 843 68, 5, 6, 55 845 Requirements that need further explanation: 846 8, 64, 68, 52 848 Requirements that are pending: 849 13, 14 851 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 852 Authors' Contact 854 Kenneth Sundell 855 Nortel Networks 856 Architecture Lab, EMEA 857 Kungsgatan 34, PO Box 1788 858 111 97 Stockholm, Sweden 859 Phone +46 8 441 7838 860 Mobile +46 70 665 7838 861 ksundell@nortelnetworks.com 863 Avri Doria 864 Nokia Telecommunications 865 3 Burlington Woods Drive, Suite 250 866 Burlington, MA 01803 867 Phone: +1 781 359 5131 868 Mobile: +1 617 678 9402 869 avri.doria@nokia.com 871 Comments on this document should be sent to the authors or to the 872 working group mailing list at gsmp@psyton.com. 874 References 876 [1] Newman, P., Edwards, W., Hinden, R., Hoffman, E, Ching Liaw, 877 F., Lyon, T. and Minshall, G., "Ipsilon's General Switch 878 Management Protocol Specification," Version 1.1, RFC 1987, 879 August 1996. 881 [2] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching 882 Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General 883 Switch Management Protocol Specification," Version 2.0, RFC 884 2397, March 1998. 886 [3] GSMP Working Group, Tom Worster Editor, "General Switch 887 Management Protocol V3", draft-ietf-gsmp-00.txt, June, 1999 889 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99 890 [4] GSMP Working Group, Doria, A., Hellstrand, F. and Adams, C. 891 "An optional abstract and resource model", 892 draft-doria-gsmp-arm-01.txt, June, 1999 894 [5] MSF Switch Control WG, McEachern, J, "Service Control 895 Interface Requirements Multiservice Switching Forum", 896 draft-mceachern-gsmp-scireq-00.txt, June, 1999 898 [6] IEEE/WG 1520, Adam, C., Lazar, A. and Nandikesan, M., 899 "The qGSMP protocol", draft-adam-gsmp-qgsmp-00.txt, June, 900 1999 902 This document expires on 20 February 2000. 904 INTERNET-DRAFT GSMP WG response to MSF SCI Requirements 20.08.99