idnits 2.17.1 draft-ietf-netconf-distributed-notif-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 397 has weird spacing: '...used to notif...' -- The document date (11 January 2022) is 834 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Downref: Normative reference to an Informational RFC: RFC 7923 == Outdated reference: A later version (-15) exists of draft-ietf-netconf-https-notif-09 == Outdated reference: A later version (-12) exists of draft-ietf-netconf-udp-notif-01 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF T. Zhou 3 Internet-Draft G. Zheng 4 Intended status: Standards Track Huawei 5 Expires: 15 July 2022 E. Voit 6 Cisco Systems 7 T. Graf 8 Swisscom 9 P. Francois 10 INSA-Lyon 11 11 January 2022 13 Subscription to Distributed Notifications 14 draft-ietf-netconf-distributed-notif-03 16 Abstract 18 This document describes extensions to the YANG notifications 19 subscription to allow metrics being published directly from 20 processors on line cards to target receivers, while subscription is 21 still maintained at the route processor in a distributed forwarding 22 system. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 15 July 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Subscription Decomposition . . . . . . . . . . . . . . . . . 6 68 6. Publication Composition . . . . . . . . . . . . . . . . . . . 6 69 7. Subscription State Change Notifications . . . . . . . . . . . 7 70 8. Publisher Configurations . . . . . . . . . . . . . . . . . . 7 71 9. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 76 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 15.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 81 A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 13 82 A.2. Configured Subscription . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 The mechanism to support a subscription of a continuous and 88 customized stream of updates from a YANG datastore is defined in 89 [RFC8639] and [RFC8641]. Requirements for Subscription to YANG 90 Datastores are defined in [RFC7923] 92 By streaming data from publishers to receivers, much better 93 performance and fine-grained sampling can be achieved than with 94 polling. In a distributed forwarding system, the packet forwarding 95 is delegated to multiple processors on line cards. To not to 96 overwhelm the route processor resources, it is not uncommon that data 97 records are published directly from processors on line cards to 98 target Receivers to further increase efficiency on the routing 99 system. 101 This documents complement the general subscription requirements 102 defined in section 4.2.1 of [RFC7923] by the paragraph: A 103 Subscription Service MAY support the ability to export from multiple 104 software processes on a single routing system and expose the 105 information which software process produced which message to maintain 106 data integrity. 108 2. Terminologies 110 The following terms are defined in [RFC8639] and are not redefined 111 here: 113 Subscriber 115 Publisher 117 Receiver 119 Subscription 121 In addition, this document defines the following terms: 123 Global Subscription: the Subscription requested by the subscriber. 124 It may be decomposed into multiple Component Subscriptions. 126 Component Subscription: is the Subscription that defines a data 127 source which is managed and controlled by a single Publisher. 129 Global Capability: is the overall subscription capability that the 130 group of Publishers can expose to the Subscriber. 132 Component Capability: is the subscription capability that each 133 Publisher can expose to the Subscriber. 135 Master: is the Publisher that interacts with the Subscriber to deal 136 with the Global Subscription. It decomposes the Global Subscription 137 to multiple Component Subscriptions and interacts with the Agents. 139 Agent: is the Publisher that interacts with the Master to deal with 140 the Component Subscription and pushing the data to the Receiver. 142 Observation Domain: An Observation Domain is the largest set of 143 Observation Points for which metrics can be collected by a metering 144 process. For example, a router line card may be an Observation 145 Domain if it is composed of several interfaces, each of which is an 146 Observation Point. In the YANG notification messages it generates, 147 the Observation Domain includes its Observation Domain ID, which is 148 unique per publisher process. That way, the collecting process can 149 identify the specific Observation Domain from the publisher that 150 sends the YANG notification messages. Every Observation Point is 151 associated with an Observation Domain. 153 Observation Domain ID: A 32-bit identifier of the Observation Domain 154 that is locally unique to the publisher process. The publisher 155 processes uses the Observation Domain ID to uniquely identify to the 156 collecting process the Observation Domain that meters the metrics. 157 Receivers SHOULD use the transport session and the Observation Domain 158 ID field to separate different publisher streams originating from the 159 same publisher. 161 3. Motivation 163 Lost and corrupt YANG notification messages need to be recognized at 164 the receiver to ensure data integrity even when multiple publisher 165 processes publishing from the same transport session. 167 To preserve data integrity down to the publisher process, the 168 Observation Domain ID in the transport message header of the YANG 169 notification message is introduced. In case of UDP transport, this 170 is described in Section 3.2 of UDP based transport 171 [I-D.ietf-netconf-udp-notif]. 173 4. Solution Overview 175 Figure 2 below shows the distributed data export framework. 177 A collector usually includes two components, 179 * the Subscriber generates the subscription instructions to express 180 what and how the Receiver want to receive the data; 182 * the Receiver is the target for the data publication. 184 For one subscription, there can be one or more Receivers. And the 185 Subscriber does not necessarily share the same IP address as the 186 Receivers. 188 In this framework, the Publisher pushes data to the Receiver 189 according to the subscription. The Publisher is either in the Master 190 or Agent role. The Master knows all the capabilities that his Agents 191 are able to provide and exposes the Global Capability to the 192 collector. The Subscriber maintains the Global Subscription at the 193 Master and disassembles the Global Subscription to multiple Component 194 Subscriptions, depending from which source data is needed. The 195 Component Subscriptions are then distributed to the corresponding 196 Publisher Agents on route and processors on line cards. 198 Publisher Agents collects metrics according to the Component 199 Subscription, add its metadata, encapsulate and pushes data to the 200 Receiver where packets are reassembled and decapsulated. 202 +-----------------------------------------+ 203 | Collector |-------------+ | 204 | +------------+ | | 205 | +------------+ || Receiver | | | 206 | | Subscriber | |--------------+ | 207 | +-----^-+----+ +------------^ | 208 | | | | | 209 +-----------------------------------------+ 210 Global | | Global | 211 Capability| | Subscription | 212 +-----------------------------------------+ 213 | | | | | 214 | +--------+-v-------------------+ | | 215 | | Publisher(Master) | | | 216 | +--------^-+-------------------+ | | 217 | | | | | 218 | | | | | 219 | Component | | Component Push | | 220 | Capability| | Subscription | | 221 | +--------+-v-------------------+ | | 222 | | Publisher(Agent) +--+ | 223 | +------------------------------+ | 224 | | 225 | Device | 226 +-----------------------------------------+ 228 Figure 1: Fig. 2 The Distributed Data Export Framework 230 Master and Agents interact with each other in several ways: 232 * Agents need to register at the Master at the beginning of their 233 process life-cycle 235 * Contracts are created between the Master and each Agent on the 236 Component Capability, and the format for streaming data structure. 238 * The Master relays the component subscriptions to the Agents. 240 * The Agents announce the status of their Component Subscriptions to 241 the Master. The status of the overall subscription is maintained 242 by the Master. The Master is responsible for notifying the 243 subscriber in case of problems with the Component Subscriptions. 245 The technical mechanisms or protocols used for the coordination of 246 operational information between Master and Agent is out-of-scope of 247 this document. 249 5. Subscription Decomposition 251 The Collector can only subscribe to the Master. This requires the 252 Master to: 254 1. expose the Global Capability that can be served by multiple 255 Publisher Agents; 257 2. disassemble the Global Subscription to multiple Component 258 Subscriptions, and distribute them to the Publisher Agents of the 259 corresponding metric sources so that they not overlap; 261 3. notify on changes when portions of a subscription moving between 262 different Publisher Agents over time. 264 And the Agent to: 266 * Inherit the Global Subscription properties from Publisher Master 267 for its Component Subscription; 269 * share the same life-cycle as the Global Subscription; 271 * share the same Subscription ID as the Global Subscription. 273 6. Publication Composition 275 The Publisher Agent collects data and encapsulates the packets per 276 Component Subscription. The format and structure of the data records 277 are defined by the YANG schema, so that the decomposition at the 278 Receiver can benefit from the structured and hierarchical data 279 records. 281 The Receiver is able to associate the YANG data records with 282 Subscription ID [RFC8639] to the subscribed subscription and with 283 Message Observation Domain ID 284 [I-D.ietf-netconf-notification-messages] to one of the Publisher 285 Agents software processes to enable message integrity. 287 For the dynamic subscription, the output of the "establish- 288 subscription" RPC defined in [RFC8639] MUST include a list of Message 289 Observation Domain IDs to indicate how the Global Subscription is 290 decomposed into several Component Subscriptions. 292 The "subscription-started" and "subscription-modified" notification 293 defined in [RFC8639] MUST also include a list of Message Observation 294 Domain IDs to notify the current Publishers for the corresponding 295 Global Subscription. 297 7. Subscription State Change Notifications 299 In addition to sending event records to Receivers, the Master MUST 300 also send subscription state change notifications [RFC8639] when 301 events related to subscription management have occurred. All the 302 subscription state change notifications MUST be delivered by the 303 Master. 305 When the subscription decomposition result changed, the 306 "subscription-modified" notification MUST be sent to indicate the new 307 list of Publishers. 309 8. Publisher Configurations 311 This document assumes that all Publisher Agents are preconfigured to 312 push data. The actual working Publisher Agents are selected based on 313 the subscription decomposition result. 315 All Publisher Agents share the same source IP address for data 316 export. For connectionless data transport such as UDP based 317 transport [I-D.ietf-netconf-udp-notif] the same Layer 4 source port 318 for data export can be used. For connection based data transport 319 such as HTTPS based transport [I-D.ietf-netconf-https-notif], each 320 Publisher Agent MUST be able to acknowledge packet retrieval from 321 Receivers, and therefore requires a dedicated Layer 4 source port per 322 software process. 324 The specific configuration on transports is described in the 325 resposible documents. 327 9. YANG Tree 329 module: ietf-distributed-notif 330 augment /sn:subscriptions/sn:subscription: 331 +--ro message-observation-domain-id* string 332 augment /sn:subscription-started: 333 +--ro message-observation-domain-id* string 334 augment /sn:subscription-modified: 335 +--ro message-observation-domain-id* string 336 augment /sn:establish-subscription/sn:output: 337 +--ro message-observation-domain-id* string 339 10. YANG Module 341 file "ietf-distributed-notif@2021-05-07.yang" 342 module ietf-distributed-notif { 343 yang-version 1.1; 344 namespace 345 "urn:ietf:params:xml:ns:yang:ietf-distributed-notif"; 346 prefix dn; 347 import ietf-subscribed-notifications { 348 prefix sn; 349 } 351 organization "IETF NETCONF (Network Configuration) Working Group"; 352 contact 353 "WG Web: 354 WG List: 356 Editor: Tianran Zhou 357 359 Editor: Guangying Zheng 360 "; 362 description 363 "Defines augmentation for ietf-subscribed-notifications to 364 enable the distributed publication with single subscription. 366 Copyright (c) 2018 IETF Trust and the persons identified as 367 authors of the code. All rights reserved. 369 Redistribution and use in source and binary forms, with or 370 without modification, is permitted pursuant to, and subject to 371 the license terms contained in, the Simplified BSD License set 372 forth in Section 4.c of the IETF Trust's Legal Provisions 373 Relating to IETF Documents 374 (https://trustee.ietf.org/license-info). 376 This version of this YANG module is part of RFC XXXX; see the 377 RFC itself for full legal notices."; 379 revision 2021-05-07 { 380 description 381 "Initial version"; 382 reference 383 "RFC XXXX: Subscription to Distributed Notifications"; 384 } 386 grouping message-observation-domain-ids { 387 description 388 "Provides a reusable list of message-observation-domain-ids."; 390 leaf-list message-observation-domain-id { 391 type string; 392 config false; 393 ordered-by user; 394 description 395 "Software process which created the message (e.g., 396 processor 1 on line card 1). This field is 397 used to notify the collector the working originator."; 398 } 399 } 401 augment "/sn:subscriptions/sn:subscription" { 402 description 403 "This augmentation allows the message 404 Observation Domain ID to be exposed for a subscription."; 406 uses message-observation-domain-ids; 407 } 409 augment "/sn:subscription-started" { 410 description 411 "This augmentation allows MSO specific parameters to be 412 exposed for a subscription."; 414 uses message-observation-domain-ids; 415 } 417 augment "/sn:subscription-modified" { 418 description 419 "This augmentation allows MSO specific parameters to be 420 exposed for a subscription."; 422 uses message-observation-domain-ids; 423 } 425 augment "/sn:establish-subscription/sn:output" { 426 description 427 "This augmentation allows MSO specific parameters to be 428 exposed for a subscription."; 430 uses message-observation-domain-ids; 431 } 432 } 433 435 11. IANA Considerations 437 This document registers the following namespace URI in the IETF XML 438 Registry [RFC3688]: 440 URI: urn:ietf:params:xml:ns:yang:ietf-distributed-notif 442 Registrant Contact: The IESG. 444 XML: N/A; the requested URI is an XML namespace. 446 This document registers the following YANG module in the YANG Module 447 Names registry [RFC3688]: 449 Name: ietf-distributed-notif 451 Namespace: urn:ietf:params:xml:ns:yang:ietf-distributed-notif 453 Prefix: dn 455 Reference: RFC XXXX 457 12. Security Considerations 459 The YANG module specified in this document defines a schema for data 460 that is designed to be accessed via network management protocols such 461 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 462 is the secure transport layer, and the mandatory-to-implement secure 463 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 464 is HTTPS, and the mandatory-to-implement secure transport is TLS 465 [RFC5246]. 467 The NETCONF Access Control Model (NACM) [RFC6536] provides the means 468 to restrict access for particular NETCONF or RESTCONF users to a 469 preconfigured subset of all available NETCONF or RESTCONF protocol 470 operations and content. 472 The new data nodes introduced in this YANG module may be considered 473 sensitive or vulnerable in some network environments. It is thus 474 important to control read access (e.g., via get-config or 475 notification) to this data nodes. These are the subtrees and data 476 nodes and their sensitivity/vulnerability: 478 * /subscriptions/subscription/message-observation-domain-ids 480 The entries in the two lists above will show where subscribed 481 resources might be located on the publishers. Access control MUST be 482 set so that only someone with proper access permissions has the 483 ability to access this resource. 485 Other Security Considerations is the same as those discussed in 486 [RFC8639]. 488 13. Contributors 490 Alexander Clemm 491 Futurewai 492 2330 Central Expressway 493 Santa Clara 494 California 495 United States of America 496 Email: ludwig@clemm.org 498 14. Acknowledgements 500 We thank Kent Watsen, Mahesh Jethanandani, Martin Bjorklund, Tim 501 Carey and Qin Wu for their constructive suggestions for improving 502 this document. 504 15. References 506 15.1. Normative References 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, 510 DOI 10.17487/RFC2119, March 1997, 511 . 513 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 514 DOI 10.17487/RFC3688, January 2004, 515 . 517 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 518 (TLS) Protocol Version 1.2", RFC 5246, 519 DOI 10.17487/RFC5246, August 2008, 520 . 522 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 523 and A. Bierman, Ed., "Network Configuration Protocol 524 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 525 . 527 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 528 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 529 . 531 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 532 Protocol (NETCONF) Access Control Model", RFC 6536, 533 DOI 10.17487/RFC6536, March 2012, 534 . 536 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 537 for Subscription to YANG Datastores", RFC 7923, 538 DOI 10.17487/RFC7923, June 2016, 539 . 541 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 542 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 543 . 545 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 546 E., and A. Tripathy, "Subscription to YANG Notifications", 547 RFC 8639, DOI 10.17487/RFC8639, September 2019, 548 . 550 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 551 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 552 September 2019, . 554 15.2. Informative References 556 [I-D.ietf-netconf-https-notif] 557 Jethanandani, M. and K. Watsen, "An HTTPS-based Transport 558 for YANG Notifications", Work in Progress, Internet-Draft, 559 draft-ietf-netconf-https-notif-09, 24 October 2021, 560 . 563 [I-D.ietf-netconf-notification-messages] 564 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 565 Clemm, "Notification Message Headers and Bundles", Work in 566 Progress, Internet-Draft, draft-ietf-netconf-notification- 567 messages-08, 17 November 2019, 568 . 571 [I-D.ietf-netconf-udp-notif] 572 Zhou, T., Zheng, G., Lucente, P., Graf, T., and P. 573 Francois, "UDP-based Transport for Configured 574 Subscriptions", Work in Progress, Internet-Draft, draft- 575 ietf-netconf-udp-notif-01, July 2020, 576 . 579 Appendix A. Examples 581 This appendix is non-normative. 583 A.1. Dynamic Subscription 585 Figure 3 shows a typical dynamic subscription to the device with 586 distributed data export capability. 588 +-------------+ +-------------+ +-------------+ 589 | Subscriber/ | | Publisher | | Publisher | 590 | Receiver | | (Master) | | (Agent) | 591 +-------------+ +------+------+ +------+------+ 592 | | | 593 | establish-subscription | | 594 +------------------------------>+ component | 595 | | subscription | 596 | RPC Reply: OK, id #22 +-------------->+ 597 | Observation Domain ID [#1,#2] | | 598 +<------------------------------+ | 599 | | | 600 | notif-mesg, id #22 | | 601 | Observation Domain ID #1 | | 602 +<------------------------------+ | 603 | | | 604 | notif-mesg, id#22 | | 605 | Observation Domain ID #2 | | 606 +<----------------------------------------------+ 607 | | | 608 | modify-subscription (id#22) | | 609 +------------------------------>+ component | 610 | | subscription | 611 | RPC Reply: OK, id #22 +-------------->+ 612 +<------------------------------+ | 613 | | | 614 | subscription-modified, id#22 | | 615 | Observation Domain ID [#1] | | 616 +<------------------------------+ | 617 | | | 618 | notif-mesg, id #22 | | 619 | Observation Domain ID #1 | | 620 +<------------------------------+ | 621 | | | 622 | | | 623 + + + 625 Figure 2: Fig. 3 Call Flow for Dynamic Subscription 627 A "establish-subscription" RPC request as per [RFC8641] is sent to 628 the Master with a successful response. An example of using NETCONF: 630 632 635 637 ds:operational 638 639 641 /ex:foo 642 643 644 500 645 646 647 649 Figure 3: Fig. 4 "establish-subscription" Request 651 As the device is able to fully satisfy the request, the request is 652 given a subscription ID of 22. The response as in Figure 5 indicates 653 that the subscription is decomposed into two component subscriptions 654 which will be published by two message Observation Domain ID: #1 and 655 #2. 657 659 661 22 662 663 669 2 670 671 673 Figure 4: Fig. 5 "establish-subscription" Positive RPC Response 675 Then, both Publishers send notifications with the corresponding piece 676 of data to the Receiver. 678 The subscriber may invoke the "modify-subscription" RPC for a 679 subscription it previously established. The RPC has no difference to 680 the single publisher case as in [RFC8641]. Figure 6 provides an 681 example where a subscriber attempts to modify the period and 682 datastore XPath filter of a subscription using NETCONF. 684 686 690 22 691 693 ds:operational 694 695 697 /ex:bar 698 699 700 250 701 702 703 705 Figure 5: Fig. 6 "modify-subscription" Request 707 If the modification is successfully accepted, the "subscription- 708 modified" subscription state notification is sent to the subscriber 709 by the Master. The notification, Figure 7 for example, indicates the 710 modified subscription is decomposed into one component subscription 711 which will be published by message Observation Domain #1. 713 714 2007-09-01T10:00:00Z 715 718 22 719 721 ds:operational 722 723 725 /ex:bar 726 727 728 250 729 730 775 2007-09-01T10:00:00Z 776 779 39 780 782 ds:operational 783 784 786 /ex:foo 787 788 789 250 790 791 797 2 798 799 800 802 Figure 8: Fig. 9 "subscription-started" Subscription State 803 Notification 805 Then, both Publishers send notifications with the corresponding data 806 record to the Receiver. 808 Authors' Addresses 810 Tianran Zhou 811 Huawei 812 156 Beiqing Rd., Haidian District 813 Beijing 814 China 816 Email: zhoutianran@huawei.com 818 Guangying Zheng 819 Huawei 820 101 Yu-Hua-Tai Software Road 821 Nanjing 822 Jiangsu, 823 China 825 Email: zhengguangying@huawei.com 827 Eric Voit 828 Cisco Systems 829 United States of America 831 Email: evoit@cisco.com 833 Thomas Graf 834 Swisscom 835 Binzring 17 836 CH- Zuerich 8045 837 Switzerland 839 Email: thomas.graf@swisscom.com 841 Pierre Francois 842 INSA-Lyon 843 Lyon 844 France 846 Email: pierre.francois@insa-lyon.fr