idnits 2.17.1 draft-ietf-netconf-distributed-notif-02.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 (May 06, 2021) is 1085 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-08 == 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: November 7, 2021 E. Voit 6 Cisco Systems 7 T. Graf 8 Swisscom 9 P. Francois 10 INSA-Lyon 11 May 06, 2021 13 Subscription to Distributed Notifications 14 draft-ietf-netconf-distributed-notif-02 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 November 7, 2021. 47 Copyright Notice 49 Copyright (c) 2021 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 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Subscription Decomposition . . . . . . . . . . . . . . . . . 6 69 6. Publication Composition . . . . . . . . . . . . . . . . . . . 6 70 7. Subscription State Change Notifications . . . . . . . . . . . 7 71 8. Publisher Configurations . . . . . . . . . . . . . . . . . . 7 72 9. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 10. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 77 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 15.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 82 A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 13 83 A.2. Configured Subscription . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 The mechanism to support a subscription of a continuous and 89 customized stream of updates from a YANG datastore is defined in 90 [RFC8639] and [RFC8641]. Requirements for Subscription to YANG 91 Datastores are defined in [RFC7923] 93 By streaming data from publishers to receivers, much better 94 performance and fine-grained sampling can be achieved than with 95 polling. In a distributed forwarding system, the packet forwarding 96 is delegated to multiple processors on line cards. To not to 97 overwhelm the route processor resources, it is not uncommon that data 98 records are published directly from processors on line cards to 99 target Receivers to further increase efficiency on the routing 100 system. 102 This documents complement the general subscription requirements 103 defined in section 4.2.1 of [RFC7923] by the paragraph: A 104 Subscription Service MAY support the ability to export from multiple 105 software processes on a single routing system and expose the 106 information which software process produced which message to maintain 107 data integrity. 109 2. Terminologies 111 The following terms are defined in [RFC8639] and are not redefined 112 here: 114 Subscriber 116 Publisher 118 Receiver 120 Subscription 122 In addition, this document defines the following terms: 124 Global Subscription: the Subscription requested by the subscriber. 125 It may be decomposed into multiple Component Subscriptions. 127 Component Subscription: is the Subscription that defines a data 128 source which is managed and controlled by a single Publisher. 130 Global Capability: is the overall subscription capability that the 131 group of Publishers can expose to the Subscriber. 133 Component Capability: is the subscription capability that each 134 Publisher can expose to the Subscriber. 136 Master: is the Publisher that interacts with the Subscriber to deal 137 with the Global Subscription. It decomposes the Global Subscription 138 to multiple Component Subscriptions and interacts with the Agents. 140 Agent: is the Publisher that interacts with the Master to deal with 141 the Component Subscription and pushing the data to the Receiver. 143 Observation Domain: An Observation Domain is the largest set of 144 Observation Points for which metrics can be collected by a metering 145 process. For example, a router line card may be an Observation 146 Domain if it is composed of several interfaces, each of which is an 147 Observation Point. In the YANG notification messages it generates, 148 the Observation Domain includes its Observation Domain ID, which is 149 unique per publisher process. That way, the collecting process can 150 identify the specific Observation Domain from the publisher that 151 sends the YANG notification messages. Every Observation Point is 152 associated with an Observation Domain. 154 Observation Domain ID: A 32-bit identifier of the Observation Domain 155 that is locally unique to the publisher process. The publisher 156 processes uses the Observation Domain ID to uniquely identify to the 157 collecting process the Observation Domain that meters the metrics. 158 Receivers SHOULD use the transport session and the Observation Domain 159 ID field to separate different publisher streams originating from the 160 same publisher. 162 3. Motivation 164 Lost and corrupt YANG notification messages need to be recognized at 165 the receiver to ensure data integrity even when multiple publisher 166 processes publishing from the same transport session. 168 To preserve data integrity down to the publisher process, the 169 Observation Domain ID in the transport message header of the YANG 170 notification message is introduced. In case of UDP transport, this 171 is described in Section 3.2 of UDP based transport 172 [I-D.ietf-netconf-udp-notif]. 174 4. Solution Overview 176 Figure 2 below shows the distributed data export framework. 178 A collector usually includes two components, 180 o the Subscriber generates the subscription instructions to express 181 what and how the Receiver want to receive the data; 183 o the Receiver is the target for the data publication. 185 For one subscription, there can be one or more Receivers. And the 186 Subscriber does not necessarily share the same IP address as the 187 Receivers. 189 In this framework, the Publisher pushes data to the Receiver 190 according to the subscription. The Publisher is either in the Master 191 or Agent role. The Master knows all the capabilities that his Agents 192 are able to provide and exposes the Global Capability to the 193 collector. The Subscriber maintains the Global Subscription at the 194 Master and disassembles the Global Subscription to multiple Component 195 Subscriptions, depending from which source data is needed. The 196 Component Subscriptions are then distributed to the corresponding 197 Publisher Agents on route and processors on line cards. 199 Publisher Agents collects metrics according to the Component 200 Subscription, add its metadata, encapsulate and pushes data to the 201 Receiver where packets are reassembled and decapsulated. 203 +-----------------------------------------+ 204 | Collector |-------------+ | 205 | +------------+ | | 206 | +------------+ || Receiver | | | 207 | | Subscriber | |--------------+ | 208 | +-----^-+----+ +------------^ | 209 | | | | | 210 +-----------------------------------------+ 211 Global | | Global | 212 Capability| | Subscription | 213 +-----------------------------------------+ 214 | | | | | 215 | +--------+-v-------------------+ | | 216 | | Publisher(Master) | | | 217 | +--------^-+-------------------+ | | 218 | | | | | 219 | | | | | 220 | Component | | Component Push | | 221 | Capability| | Subscription | | 222 | +--------+-v-------------------+ | | 223 | | Publisher(Agent) +--+ | 224 | +------------------------------+ | 225 | | 226 | Device | 227 +-----------------------------------------+ 229 Fig. 2 The Distributed Data Export Framework 231 Master and Agents interact with each other in several ways: 233 o Agents need to register at the Master at the beginning of their 234 process life-cycle 236 o Contracts are created between the Master and each Agent on the 237 Component Capability, and the format for streaming data structure. 239 o The Master relays the component subscriptions to the Agents. 241 o The Agents announce the status of their Component Subscriptions to 242 the Master. The status of the overall subscription is maintained 243 by the Master. The Master is responsible for notifying the 244 subscriber in case of problems with the Component Subscriptions. 246 The technical mechanisms or protocols used for the coordination of 247 operational information between Master and Agent is out-of-scope of 248 this document. 250 5. Subscription Decomposition 252 The Collector can only subscribe to the Master. This requires the 253 Master to: 255 1. expose the Global Capability that can be served by multiple 256 Publisher Agents; 258 2. disassemble the Global Subscription to multiple Component 259 Subscriptions, and distribute them to the Publisher Agents of the 260 corresponding metric sources so that they not overlap; 262 3. notify on changes when portions of a subscription moving between 263 different Publisher Agents over time. 265 And the Agent to: 267 o Inherit the Global Subscription properties from Publisher Master 268 for its Component Subscription; 270 o share the same life-cycle as the Global Subscription; 272 o share the same Subscription ID as the Global Subscription. 274 6. Publication Composition 276 The Publisher Agent collects data and encapsulates the packets per 277 Component Subscription. The format and structure of the data records 278 are defined by the YANG schema, so that the decomposition at the 279 Receiver can benefit from the structured and hierarchical data 280 records. 282 The Receiver is able to associate the YANG data records with 283 Subscription ID [RFC8639] to the subscribed subscription and with 284 Message Observation Domain ID 285 [I-D.ietf-netconf-notification-messages] to one of the Publisher 286 Agents software processes to enable message integrity. 288 For the dynamic subscription, the output of the "establish- 289 subscription" RPC defined in [RFC8639] MUST include a list of Message 290 Observation Domain IDs to indicate how the Global Subscription is 291 decomposed into several Component Subscriptions. 293 The "subscription-started" and "subscription-modified" notification 294 defined in [RFC8639] MUST also include a list of Message Observation 295 Domain IDs to notify the current Publishers for the corresponding 296 Global Subscription. 298 7. Subscription State Change Notifications 300 In addition to sending event records to Receivers, the Master MUST 301 also send subscription state change notifications [RFC8639] when 302 events related to subscription management have occurred. All the 303 subscription state change notifications MUST be delivered by the 304 Master. 306 When the subscription decomposition result changed, the 307 "subscription-modified" notification MUST be sent to indicate the new 308 list of Publishers. 310 8. Publisher Configurations 312 This document assumes that all Publisher Agents are preconfigured to 313 push data. The actual working Publisher Agents are selected based on 314 the subscription decomposition result. 316 All Publisher Agents share the same source IP address for data 317 export. For connectionless data transport such as UDP based 318 transport [I-D.ietf-netconf-udp-notif] the same Layer 4 source port 319 for data export can be used. For connection based data transport 320 such as HTTPS based transport [I-D.ietf-netconf-https-notif], each 321 Publisher Agent MUST be able to acknowledge packet retrieval from 322 Receivers, and therefore requires a dedicated Layer 4 source port per 323 software process. 325 The specific configuration on transports is described in the 326 resposible documents. 328 9. YANG Tree 329 module: ietf-distributed-notifications 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-notifications@2020-05-09.yang" 342 module ietf-distributed-notif { 343 yang-version 1.1; 344 namespace 345 "urn:ietf:params:xml:ns:yang:ietf-distributed-notifications"; 346 prefix mso; 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 2020-05-09 { 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 } 424 augment "/sn:establish-subscription/sn:output" { 425 description 426 "This augmentation allows MSO specific parameters to be 427 exposed for a subscription."; 429 uses message-observation-domain-ids; 430 } 431 } 432 434 11. IANA Considerations 436 This document registers the following namespace URI in the IETF XML 437 Registry [RFC3688]: 439 URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications 441 Registrant Contact: The IESG. 443 XML: N/A; the requested URI is an XML namespace. 445 This document registers the following YANG module in the YANG Module 446 Names registry [RFC3688]: 448 Name: ietf-subscribed-notifications 450 Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed- 451 notifications 453 Prefix: mso 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 o /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 YANG- 486 Push [RFC8641]. 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", draft-ietf-netconf-https-notif-08 559 (work in progress), February 2021. 561 [I-D.ietf-netconf-notification-messages] 562 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 563 Clemm, "Notification Message Headers and Bundles", draft- 564 ietf-netconf-notification-messages-08 (work in progress), 565 November 2019. 567 [I-D.ietf-netconf-udp-notif] 568 Zhou, T., Zheng, G., Lucente, P., Graf, T., and P. 569 Francois, "UDP-based Transport for Configured 570 Subscriptions", draft-ietf-netconf-udp-notif-01 (work in 571 progress), July 2020. 573 Appendix A. Examples 575 This appendix is non-normative. 577 A.1. Dynamic Subscription 579 Figure 3 shows a typical dynamic subscription to the device with 580 distributed data export capability. 582 +-------------+ +-------------+ +-------------+ 583 | Subscriber/ | | Publisher | | Publisher | 584 | Receiver | | (Master) | | (Agent) | 585 +-------------+ +------+------+ +------+------+ 586 | | | 587 | establish-subscription | | 588 +------------------------------>+ component | 589 | | subscription | 590 | RPC Reply: OK, id #22 +-------------->+ 591 | Observation Domain ID [#1,#2] | | 592 +<------------------------------+ | 593 | | | 594 | notif-mesg, id #22 | | 595 | Observation Domain ID #1 | | 596 +<------------------------------+ | 597 | | | 598 | notif-mesg, id#22 | | 599 | Observation Domain ID #2 | | 600 +<----------------------------------------------+ 601 | | | 602 | modify-subscription (id#22) | | 603 +------------------------------>+ component | 604 | | subscription | 605 | RPC Reply: OK, id #22 +-------------->+ 606 +<------------------------------+ | 607 | | | 608 | subscription-modified, id#22 | | 609 | Observation Domain ID [#1] | | 610 +<------------------------------+ | 611 | | | 612 | notif-mesg, id #22 | | 613 | Observation Domain ID #1 | | 614 +<------------------------------+ | 615 | | | 616 | | | 617 + + + 619 Fig. 3 Call Flow for Dynamic Subscription 621 A "establish-subscription" RPC request as per [RFC8641] is sent to 622 the Master with a successful response. An example of using NETCONF: 624 626 629 631 ds:operational 632 633 635 /ex:foo 636 637 638 500 639 640 641 643 Fig. 4 "establish-subscription" Request 645 As the device is able to fully satisfy the request, the request is 646 given a subscription ID of 22. The response as in Figure 5 indicates 647 that the subscription is decomposed into two component subscriptions 648 which will be published by two message Observation Domain ID: #1 and 649 #2. 651 653 655 22 656 657 663 2 664 665 667 Fig. 5 "establish-subscription" Positive RPC Response 669 Then, both Publishers send notifications with the corresponding piece 670 of data to the Receiver. 672 The subscriber may invoke the "modify-subscription" RPC for a 673 subscription it previously established. The RPC has no difference to 674 the single publisher case as in [RFC8641]. Figure 6 provides an 675 example where a subscriber attempts to modify the period and 676 datastore XPath filter of a subscription using NETCONF. 678 680 684 22 685 687 ds:operational 688 689 691 /ex:bar 692 693 694 250 695 696 697 699 Fig. 6 "modify-subscription" Request 701 If the modification is successfully accepted, the "subscription- 702 modified" subscription state notification is sent to the subscriber 703 by the Master. The notification, Figure 7 for example, indicates the 704 modified subscription is decomposed into one component subscription 705 which will be published by message Observation Domain #1. 707 708 2007-09-01T10:00:00Z 709 712 22 713 715 ds:operational 716 717 719 /ex:bar 720 721 722 250 723 724 768 2007-09-01T10:00:00Z 769 772 39 773 775 ds:operational 776 777 779 /ex:foo 780 781 782 250 783 784 790 2 791 792 793 795 Fig. 9 "subscription-started" Subscription State Notification 797 Then, both Publishers send notifications with the corresponding data 798 record to the Receiver. 800 Authors' Addresses 802 Tianran Zhou 803 Huawei 804 156 Beiqing Rd., Haidian District 805 Beijing 806 China 808 Email: zhoutianran@huawei.com 809 Guangying Zheng 810 Huawei 811 101 Yu-Hua-Tai Software Road 812 Nanjing, Jiangsu 813 China 815 Email: zhengguangying@huawei.com 817 Eric Voit 818 Cisco Systems 819 United States of America 821 Email: evoit@cisco.com 823 Thomas Graf 824 Swisscom 825 Binzring 17 826 Zuerich 8045 827 Switzerland 829 Email: thomas.graf@swisscom.com 831 Pierre Francois 832 INSA-Lyon 833 Lyon 834 France 836 Email: pierre.francois@insa-lyon.fr