idnits 2.17.1 draft-ietf-netconf-distributed-notif-01.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 396 has weird spacing: '...used to notif...' -- The document date (November 02, 2020) is 1233 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-05 == 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: May 6, 2021 E. Voit 6 Cisco Systems 7 T. Graf 8 Swisscom 9 P. Francois 10 INSA-Lyon 11 November 02, 2020 13 Subscription to Distributed Notifications 14 draft-ietf-netconf-distributed-notif-01 16 Abstract 18 This documents 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 May 6, 2021. 47 Copyright Notice 49 Copyright (c) 2020 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 to 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 overhelm the route processor resources, it is not uncomon that data 98 records are published directly from processors on line cards to 99 target Receivers to further increase efficency on the routing 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 collector. 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 process 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 o the Subscriber generates the subscription instructions to express 180 what and how the collector want to receive the data; 182 o the Receiver is the target for the data publication. 184 For one subscription, there are 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 Fig. 2 The Distributed Data Export Framework 230 Master and Agents interact with each other in several ways: 232 o Agents need to register at the Master at the beginning of their 233 process life-cycle 235 o Contracts are created between the Master and each Agent on the 236 Component Capability, and the format for streaming data structure. 238 o The Master relays the component subscriptions to the Agents. 240 o 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 o Inherit the Global Subscription properties from Publisher Master 267 for its Component Subscription; 269 o share the same life-cycle as the Global Subscription; 271 o 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 328 module: ietf-distributed-notifications 329 augment /sn:subscriptions/sn:subscription: 330 +--ro message-observation-domain-id* string 331 augment /sn:subscription-started: 332 +--ro message-observation-domain-id* string 333 augment /sn:subscription-modified: 334 +--ro message-observation-domain-id* string 335 augment /sn:establish-subscription/sn:output: 336 +--ro message-observation-domain-id* string 338 10. YANG Module 340 file "ietf-distributed-notifications@2020-05-09.yang" 341 module ietf-distributed-notif { 342 yang-version 1.1; 343 namespace 344 "urn:ietf:params:xml:ns:yang:ietf-distributed-notifications"; 345 prefix mso; 346 import ietf-subscribed-notifications { 347 prefix sn; 348 } 350 organization "IETF NETCONF (Network Configuration) Working Group"; 351 contact 352 "WG Web: 353 WG List: 355 Editor: Tianran Zhou 356 358 Editor: Guangying Zheng 359 "; 361 description 362 "Defines augmentation for ietf-subscribed-notifications to 363 enable the distributed publication with single subscription. 365 Copyright (c) 2018 IETF Trust and the persons identified as 366 authors of the code. All rights reserved. 368 Redistribution and use in source and binary forms, with or 369 without modification, is permitted pursuant to, and subject to 370 the license terms contained in, the Simplified BSD License set 371 forth in Section 4.c of the IETF Trust's Legal Provisions 372 Relating to IETF Documents 373 (https://trustee.ietf.org/license-info). 375 This version of this YANG module is part of RFC XXXX; see the 376 RFC itself for full legal notices."; 378 revision 2020-05-09 { 379 description 380 "Initial version"; 381 reference 382 "RFC XXXX: Subscription to Distributed Notifications"; 383 } 385 grouping message-observation-domain-ids { 386 description 387 "Provides a reusable list of message-observation-domain-ids."; 389 leaf-list message-observation-domain-id { 390 type string; 391 config false; 392 ordered-by user; 393 description 394 "Software process which created the message (e.g., 395 processor 1 on linecard 1). This field is 396 used to notify the collector the working originator."; 397 } 398 } 400 augment "/sn:subscriptions/sn:subscription" { 401 description 402 "This augmentation allows the message 403 Observation Domain ID to be exposed for a subscription."; 405 uses message-observation-domain-ids; 406 } 408 augment "/sn:subscription-started" { 409 description 410 "This augmentation allows MSO specific parameters to be 411 exposed for a subscription."; 413 uses message-observation-domain-ids; 414 } 416 augment "/sn:subscription-modified" { 417 description 418 "This augmentation allows MSO specific parameters to be 419 exposed for a subscription."; 421 uses message-observation-domain-ids; 422 } 423 augment "/sn:establish-subscription/sn:output" { 424 description 425 "This augmentation allows MSO specific parameters to be 426 exposed for a subscription."; 428 uses message-observation-domain-ids; 429 } 430 } 431 433 11. IANA Considerations 435 This document registers the following namespace URI in the IETF XML 436 Registry [RFC3688]: 438 URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications 440 Registrant Contact: The IESG. 442 XML: N/A; the requested URI is an XML namespace. 444 This document registers the following YANG module in the YANG Module 445 Names registry [RFC3688]: 447 Name: ietf-subscribed-notifications 449 Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed- 450 notifications 452 Prefix: mso 454 Reference: RFC XXXX 456 12. Security Considerations 458 The YANG module specified in this document defines a schema for data 459 that is designed to be accessed via network management protocols such 460 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 461 is the secure transport layer, and the mandatory-to-implement secure 462 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 463 is HTTPS, and the mandatory-to-implement secure transport is TLS 464 [RFC5246]. 466 The NETCONF Access Control Model (NACM) [RFC6536] provides the means 467 to restrict access for particular NETCONF or RESTCONF users to a 468 preconfigured subset of all available NETCONF or RESTCONF protocol 469 operations and content. 471 The new data nodes introduced in this YANG module may be considered 472 sensitive or vulnerable in some network environments. It is thus 473 important to control read access (e.g., via get-config or 474 notification) to this data nodes. These are the subtrees and data 475 nodes and their sensitivity/vulnerability: 477 o /subscriptions/subscription/message-observation-domain-ids 479 The entries in the two lists above will show where subscribed 480 resources might be located on the publishers. Access control MUST be 481 set so that only someone with proper access permissions has the 482 ability to access this resource. 484 Other Security Considerations is the same as those discussed in YANG- 485 Push [RFC8641]. 487 13. Contributors 489 Alexander Clemm 490 Futurewai 491 2330 Central Expressway 492 Santa Clara 493 California 494 United States of America 495 Email: ludwig@clemm.org 497 14. Acknowledgements 499 We thank Kent Watsen, Mahesh Jethanandani, Martin Bjorklund, Tim 500 Carey and Qin Wu for their constructive suggestions for improving 501 this document. 503 15. References 505 15.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 513 DOI 10.17487/RFC3688, January 2004, 514 . 516 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 517 (TLS) Protocol Version 1.2", RFC 5246, 518 DOI 10.17487/RFC5246, August 2008, 519 . 521 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 522 and A. Bierman, Ed., "Network Configuration Protocol 523 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 524 . 526 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 527 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 528 . 530 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 531 Protocol (NETCONF) Access Control Model", RFC 6536, 532 DOI 10.17487/RFC6536, March 2012, 533 . 535 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 536 for Subscription to YANG Datastores", RFC 7923, 537 DOI 10.17487/RFC7923, June 2016, 538 . 540 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 541 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 542 . 544 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 545 E., and A. Tripathy, "Subscription to YANG Notifications", 546 RFC 8639, DOI 10.17487/RFC8639, September 2019, 547 . 549 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 550 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 551 September 2019, . 553 15.2. Informative References 555 [I-D.ietf-netconf-https-notif] 556 Jethanandani, M. and K. Watsen, "An HTTPS-based Transport 557 for Configured Subscriptions", draft-ietf-netconf-https- 558 notif-05 (work in progress), October 2020. 560 [I-D.ietf-netconf-notification-messages] 561 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 562 Clemm, "Notification Message Headers and Bundles", draft- 563 ietf-netconf-notification-messages-08 (work in progress), 564 November 2019. 566 [I-D.ietf-netconf-udp-notif] 567 Zhou, T., Zheng, G., Lucente, P., Graf, T., and P. 568 Francois, "UDP-based Transport for Configured 569 Subscriptions", draft-ietf-netconf-udp-notif-01 (work in 570 progress), July 2020. 572 Appendix A. Examples 574 This appendix is non-normative. 576 A.1. Dynamic Subscription 578 Figure 3 shows a typical dynamic subscription to the device with 579 distributed data export capability. 581 +-------------+ +-------------+ +-------------+ 582 | Subscriber/ | | Publisher | | Publisher | 583 | Receiver | | (Master) | | (Agent) | 584 +-------------+ +------+------+ +------+------+ 585 | | | 586 | establish-subscription | | 587 +------------------------------>+ component | 588 | | subscription | 589 | RPC Reply: OK, id #22 +-------------->+ 590 | Observation Domain ID [#1,#2] | | 591 +<------------------------------+ | 592 | | | 593 | notif-mesg, id #22 | | 594 | Observation Domain ID #1 | | 595 +<------------------------------+ | 596 | | | 597 | notif-mesg, id#22 | | 598 | Observation Domain ID #2 | | 599 +<----------------------------------------------+ 600 | | | 601 | modify-subscription (id#22) | | 602 +------------------------------>+ component | 603 | | subscription | 604 | RPC Reply: OK, id #22 +-------------->+ 605 +<------------------------------+ | 606 | | | 607 | subscription-modified, id#22 | | 608 | Observation Domain ID [#1] | | 609 +<------------------------------+ | 610 | | | 611 | notif-mesg, id #22 | | 612 | Observation Domain ID #1 | | 613 +<------------------------------+ | 614 | | | 615 | | | 616 + + + 618 Fig. 3 Call Flow for Dynamic Subscription 620 A "establish-subscription" RPC request as per [RFC8641] is sent to 621 the Master with a successful response. An example of using NETCONF: 623 625 628 630 ds:operational 631 632 634 /ex:foo 635 636 637 500 638 639 640 642 Fig. 4 "establish-subscription" Request 644 As the device is able to fully satisfy the request, the request is 645 given a subscription ID of 22. The response as in Figure 5 indicates 646 that the subscription is decomposed into two component subscriptions 647 which will be published by two message Observation Domain ID: #1 and 648 #2. 650 652 654 22 655 656 662 2 663 664 666 Fig. 5 "establish-subscription" Positive RPC Response 668 Then, both Publishers send notifications with the corresponding piece 669 of data to the Receiver. 671 The subscriber may invoke the "modify-subscription" RPC for a 672 subscription it previously established. The RPC has no difference to 673 the single publisher case as in [RFC8641]. Figure 6 provides an 674 example where a subscriber attempts to modify the period and 675 datastore XPath filter of a subscription using NETCONF. 677 679 683 22 684 686 ds:operational 687 688 690 /ex:bar 691 692 693 250 694 695 696 698 Fig. 6 "modify-subscription" Request 700 If the modification is successfully accepted, the "subscription- 701 modified" subscription state notification is sent to the subscriber 702 by the Master. The notification, Figure 7 for example, indicates the 703 modified subscription is decomposed into one component subscription 704 which will be published by message Observation Domain #1. 706 707 2007-09-01T10:00:00Z 708 711 22 712 714 ds:operational 715 716 718 /ex:bar 719 720 721 250 722 723 767 2007-09-01T10:00:00Z 768 771 39 772 774 ds:operational 775 776 778 /ex:foo 779 780 781 250 782 783 789 2 790 791 792 794 Fig. 9 "subscription-started" Subscription State Notification 796 Then, both Publishers send notifications with the corresponding data 797 record to the Receiver. 799 Authors' Addresses 801 Tianran Zhou 802 Huawei 803 156 Beiqing Rd., Haidian District 804 Beijing 805 China 807 Email: zhoutianran@huawei.com 808 Guangying Zheng 809 Huawei 810 101 Yu-Hua-Tai Software Road 811 Nanjing, Jiangsu 812 China 814 Email: zhengguangying@huawei.com 816 Eric Voit 817 Cisco Systems 818 United States of America 820 Email: evoit@cisco.com 822 Thomas Graf 823 Swisscom 824 Binzring 17 825 Zuerich 8045 826 Switzerland 828 Email: thomas.graf@swisscom.com 830 Pierre Francois 831 INSA-Lyon 832 Lyon 833 France 835 Email: pierre.francois@insa-lyon.fr