| < draft-ietf-p2psip-diagnostics-21.txt | draft-ietf-p2psip-diagnostics-22.txt > | |||
|---|---|---|---|---|
| P2PSIP Working Group H. Song | P2PSIP Working Group H. Song | |||
| Internet-Draft X. Jiang | Internet-Draft X. Jiang | |||
| Intended status: Standards Track R. Even | Intended status: Standards Track R. Even | |||
| Expires: August 30, 2016 Huawei | Expires: September 25, 2016 Huawei | |||
| D. Bryan | D. Bryan | |||
| ethernot.org | ethernot.org | |||
| Y. Sun | Y. Sun | |||
| ICT | ICT | |||
| February 27, 2016 | March 24, 2016 | |||
| P2P Overlay Diagnostics | P2P Overlay Diagnostics | |||
| draft-ietf-p2psip-diagnostics-21 | draft-ietf-p2psip-diagnostics-22 | |||
| Abstract | Abstract | |||
| This document describes mechanisms for P2P overlay diagnostics. It | This document describes mechanisms for P2P overlay diagnostics. It | |||
| defines extensions to the RELOAD base protocol to collect diagnostic | defines extensions to the RELOAD base protocol to collect diagnostic | |||
| information, and details the protocol specifications for these | information, and details the protocol specifications for these | |||
| extensions. Useful diagnostic information for connection and node | extensions. Useful diagnostic information for connection and node | |||
| status monitoring is also defined. The document also describes the | status monitoring is also defined. The document also describes the | |||
| usage scenarios and provides examples of how these methods are used | usage scenarios and provides examples of how these methods are used | |||
| to perform diagnostics. | to perform diagnostics. | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on August 30, 2016. | This Internet-Draft will expire on September 25, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 3, line 13 ¶ | skipping to change at page 3, line 13 ¶ | |||
| Appendix C. Changes to the Draft . . . . . . . . . . . . . . . . 28 | Appendix C. Changes to the Draft . . . . . . . . . . . . . . . . 28 | |||
| C.1. Changes since -00 version . . . . . . . . . . . . . . . . 29 | C.1. Changes since -00 version . . . . . . . . . . . . . . . . 29 | |||
| C.2. Changes since -01 version . . . . . . . . . . . . . . . . 29 | C.2. Changes since -01 version . . . . . . . . . . . . . . . . 29 | |||
| C.3. Changes since -02 version . . . . . . . . . . . . . . . . 29 | C.3. Changes since -02 version . . . . . . . . . . . . . . . . 29 | |||
| C.4. Changes since -03 version . . . . . . . . . . . . . . . . 29 | C.4. Changes since -03 version . . . . . . . . . . . . . . . . 29 | |||
| C.5. Changes since -04 version . . . . . . . . . . . . . . . . 29 | C.5. Changes since -04 version . . . . . . . . . . . . . . . . 29 | |||
| C.6. Changes since -05 version . . . . . . . . . . . . . . . . 29 | C.6. Changes since -05 version . . . . . . . . . . . . . . . . 29 | |||
| C.7. Changes in version -10 . . . . . . . . . . . . . . . . . 29 | C.7. Changes in version -10 . . . . . . . . . . . . . . . . . 29 | |||
| C.8. Changes in version -15 . . . . . . . . . . . . . . . . . 30 | C.8. Changes in version -15 . . . . . . . . . . . . . . . . . 30 | |||
| C.9. Changes in version -20 . . . . . . . . . . . . . . . . . 30 | C.9. Changes in version -20 . . . . . . . . . . . . . . . . . 30 | |||
| C.10. Changes in version -22 . . . . . . . . . . . . . . . . . 31 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
| 1. Introduction | 1. Introduction | |||
| In the last few years, overlay networks have rapidly evolved and | In the last few years, overlay networks have rapidly evolved and | |||
| emerged as a promising platform for deployment of new applications | emerged as a promising platform for deployment of new applications | |||
| and services in the Internet. One of the reasons overlay networks | and services in the Internet. One of the reasons overlay networks | |||
| are seen as an excellent platform for large scale distributed systems | are seen as an excellent platform for large scale distributed systems | |||
| is their resilience in the presence of failures. This resilience has | is their resilience in the presence of failures. This resilience has | |||
| three aspects: data replication, routing recovery, and static | three aspects: data replication, routing recovery, and static | |||
| skipping to change at page 23, line 10 ¶ | skipping to change at page 23, line 10 ¶ | |||
| in a 64-bits long integer dMFlags denoting diagnostic information to | in a 64-bits long integer dMFlags denoting diagnostic information to | |||
| be retrieved as described in Section 4.3.1. New entries SHALL be | be retrieved as described in Section 4.3.1. New entries SHALL be | |||
| defined via [RFC5226] Standards Action. The initial contents of this | defined via [RFC5226] Standards Action. The initial contents of this | |||
| registry are: | registry are: | |||
| +-------------------------+----------------------------+----------+ | +-------------------------+----------------------------+----------+ | |||
| | diagnostic information |diagnostic flag in dMFlags | RFC | | | diagnostic information |diagnostic flag in dMFlags | RFC | | |||
| |-------------------------+----------------------------+----------| | |-------------------------+----------------------------+----------| | |||
| |Reserved All 0s value | 0x 0000 0000 0000 0000 |RFC-[TBDX]| | |Reserved All 0s value | 0x 0000 0000 0000 0000 |RFC-[TBDX]| | |||
| |Reserved First Bit | 0x 0000 0000 0000 0001 |RFC-[TBDX]| | |Reserved First Bit | 0x 0000 0000 0000 0001 |RFC-[TBDX]| | |||
| |STATUS_INFO | 0x 0000 0000 0000 0001 |RFC-[TBDX]| | |STATUS_INFO | 0x 0000 0000 0000 0002 |RFC-[TBDX]| | |||
| |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0002 |RFC-[TBDX]| | |ROUTING_TABLE_SIZE | 0x 0000 0000 0000 0004 |RFC-[TBDX]| | |||
| |PROCESS_POWER | 0x 0000 0000 0000 0004 |RFC-[TBDX]| | |PROCESS_POWER | 0x 0000 0000 0000 0008 |RFC-[TBDX]| | |||
| |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0008 |RFC-[TBDX]| | |UPSTREAM_BANDWIDTH | 0x 0000 0000 0000 0010 |RFC-[TBDX]| | |||
| |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0010 |RFC-[TBDX]| | |DOWNSTREAM_ BANDWIDTH | 0x 0000 0000 0000 0020 |RFC-[TBDX]| | |||
| |SOFTWARE_VERSION | 0x 0000 0000 0000 0020 |RFC-[TBDX]| | |SOFTWARE_VERSION | 0x 0000 0000 0000 0040 |RFC-[TBDX]| | |||
| |MACHINE_UPTIME | 0x 0000 0000 0000 0040 |RFC-[TBDX]| | |MACHINE_UPTIME | 0x 0000 0000 0000 0080 |RFC-[TBDX]| | |||
| |APP_UPTIME | 0x 0000 0000 0000 0080 |RFC-[TBDX]| | |APP_UPTIME | 0x 0000 0000 0000 0100 |RFC-[TBDX]| | |||
| |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0100 |RFC-[TBDX]| | |MEMORY_FOOTPRINT | 0x 0000 0000 0000 0200 |RFC-[TBDX]| | |||
| |DATASIZE_STORED | 0x 0000 0000 0000 0200 |RFC-[TBDX]| | |DATASIZE_STORED | 0x 0000 0000 0000 0400 |RFC-[TBDX]| | |||
| |INSTANCES_STORED | 0x 0000 0000 0000 0400 |RFC-[TBDX]| | |INSTANCES_STORED | 0x 0000 0000 0000 0800 |RFC-[TBDX]| | |||
| |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 0800 |RFC-[TBDX]| | |MESSAGES_SENT_RCVD | 0x 0000 0000 0000 1000 |RFC-[TBDX]| | |||
| |EWMA_BYTES_SENT | 0x 0000 0000 0000 1000 |RFC-[TBDX]| | |EWMA_BYTES_SENT | 0x 0000 0000 0000 2000 |RFC-[TBDX]| | |||
| |EWMA_BYTES_RCVD | 0x 0000 0000 0000 2000 |RFC-[TBDX]| | |EWMA_BYTES_RCVD | 0x 0000 0000 0000 4000 |RFC-[TBDX]| | |||
| |UNDERLAY_HOP | 0x 0000 0000 0000 4000 |RFC-[TBDX]| | |UNDERLAY_HOP | 0x 0000 0000 0000 8000 |RFC-[TBDX]| | |||
| |BATTERY_STATUS | 0x 0000 0000 0000 8000 |RFC-[TBDX]| | |BATTERY_STATUS | 0x 0000 0000 0001 0000 |RFC-[TBDX]| | |||
| |Reserved Last Bit | 0x 8000 0000 0000 0000 |RFC-[TBDX]| | |Reserved Last Bit | 0x 8000 0000 0000 0000 |RFC-[TBDX]| | |||
| |Reserved All 1s value | 0x FFFF FFFF FFFF FFFF |RFC-[TBDX]| | |Reserved All 1s value | 0x FFFF FFFF FFFF FFFF |RFC-[TBDX]| | |||
| +-------------------------+----------------------------+----------+ | +-------------------------+----------------------------+----------+ | |||
| [To RFC editor: Please replace all RFC-[TBDX] in this document with | [To RFC editor: Please replace all RFC-[TBDX] in this document with | |||
| the RFC number of this document.] | the RFC number of this document.] | |||
| 9.2. Diagnostic Kind ID | 9.2. Diagnostic Kind ID | |||
| IANA is asked to create a "RELOAD Diagnostic Kind ID" Registry under | IANA is asked to create a "RELOAD Diagnostic Kind ID" Registry under | |||
| protocol RELOAD. Entries in this registry are 16-bit integers | protocol RELOAD. Entries in this registry are 16-bit integers | |||
| denoting diagnostics extension data kinds carried in the diagnostic | denoting diagnostics extension data kinds carried in the diagnostic | |||
| request and response message, as described in Section 5.2. Code | request and response message, as described in Section 5.2. Code | |||
| points from 0x0000 to 0x003F are asked to be assigned together with | points from 0x0001 to 0x003E are asked to be assigned together with | |||
| flags within "RELOAD Diagnostics Flag" registry via RFC 5226 | flags within "RELOAD Diagnostics Flag" registry via RFC 5226 | |||
| [RFC5226] standards action. Code points in the range 0x0040 to | [RFC5226] standards action. Code points in the range 0x003F to | |||
| 0xEFFF SHALL be registered via RFC 5226 standards action. | 0xEFFF SHALL be registered via RFC 5226 standards action. | |||
| +---------------------------+---------------+---------------+ | +---------------------------+---------------+---------------+ | |||
| | Diagnostic Kind | Code | Specification | | | Diagnostic Kind | Code | Specification | | |||
| +---------------------------+---------------+---------------+ | +---------------------------+---------------+---------------+ | |||
| | reserved | 0x0000 | RFC-[TBDX] | | | reserved | 0x0000 | RFC-[TBDX] | | |||
| | STATUS_INFO | 0x0001 | RFC-[TBDX] | | | STATUS_INFO | 0x0001 | RFC-[TBDX] | | |||
| | ROUTING_TABLE_SIZE | 0x0002 | RFC-[TBDX] | | | ROUTING_TABLE_SIZE | 0x0002 | RFC-[TBDX] | | |||
| | PROCESS_POWER | 0x0003 | RFC-[TBDX] | | | PROCESS_POWER | 0x0003 | RFC-[TBDX] | | |||
| | UPSTREAM_BANDWIDTH | 0x0004 | RFC-[TBDX] | | | UPSTREAM_BANDWIDTH | 0x0004 | RFC-[TBDX] | | |||
| skipping to change at page 24, line 25 ¶ | skipping to change at page 24, line 25 ¶ | |||
| | MACHINE_UPTIME | 0x0007 | RFC-[TBDX] | | | MACHINE_UPTIME | 0x0007 | RFC-[TBDX] | | |||
| | APP_UPTIME | 0x0008 | RFC-[TBDX] | | | APP_UPTIME | 0x0008 | RFC-[TBDX] | | |||
| | MEMORY_FOOTPRINT | 0x0009 | RFC-[TBDX] | | | MEMORY_FOOTPRINT | 0x0009 | RFC-[TBDX] | | |||
| | DATASIZE_STORED | 0x000A | RFC-[TBDX] | | | DATASIZE_STORED | 0x000A | RFC-[TBDX] | | |||
| | INSTANCES_STORED | 0x000B | RFC-[TBDX] | | | INSTANCES_STORED | 0x000B | RFC-[TBDX] | | |||
| | MESSAGES_SENT_RCVD | 0x000C | RFC-[TBDX] | | | MESSAGES_SENT_RCVD | 0x000C | RFC-[TBDX] | | |||
| | EWMA_BYTES_SENT | 0x000D | RFC-[TBDX] | | | EWMA_BYTES_SENT | 0x000D | RFC-[TBDX] | | |||
| | EWMA_BYTES_RCVD | 0x000E | RFC-[TBDX] | | | EWMA_BYTES_RCVD | 0x000E | RFC-[TBDX] | | |||
| | UNDERLAY_HOP | 0x000F | RFC-[TBDX] | | | UNDERLAY_HOP | 0x000F | RFC-[TBDX] | | |||
| | BATTERY_STATUS | 0x0010 | RFC-[TBDX] | | | BATTERY_STATUS | 0x0010 | RFC-[TBDX] | | |||
| | reserved for future flags | 0x0011-40 | RFC-[TBDX] | | | reserved for future flags | 0x0011-3E | RFC-[TBDX] | | |||
| | local use (reserved) | 0xF000-0xFFFE | RFC-[TBDX] | | | local use (reserved) | 0xF000-0xFFFE | RFC-[TBDX] | | |||
| | reserved | 0xFFFF | RFC-[TBDX] | | | reserved | 0xFFFF | RFC-[TBDX] | | |||
| +---------------------------+---------------+---------------+ | +---------------------------+---------------+---------------+ | |||
| Table 1: Diagnostic Kind | Table 1: Diagnostic Kind | |||
| 9.3. Message Codes | 9.3. Message Codes | |||
| This document introduces two new types of messages and their | This document introduces two new types of messages and their | |||
| responses, requiring the following additions to the "RELOAD Message | responses, requiring the following additions to the "RELOAD Message | |||
| skipping to change at page 31, line 11 ¶ | skipping to change at page 31, line 11 ¶ | |||
| "direct response routing or via symmetric routing", and give a | "direct response routing or via symmetric routing", and give a | |||
| reference to direct response routing RFC, according to the list | reference to direct response routing RFC, according to the list | |||
| discussion with Alvaro | discussion with Alvaro | |||
| (11) change Section 5.3 and 9.1 about the reserved dMFlags bits | (11) change Section 5.3 and 9.1 about the reserved dMFlags bits | |||
| issue according to Jari and Alexey's comment | issue according to Jari and Alexey's comment | |||
| (12) replace "diagnostic kind type" with "diagnostic Kind" | (12) replace "diagnostic kind type" with "diagnostic Kind" | |||
| (12) correct other minor editorial issues | (12) correct other minor editorial issues | |||
| C.10. Changes in version -22 | ||||
| (1) fix the bugs in IANA section | ||||
| Authors' Addresses | Authors' Addresses | |||
| Haibin Song | Haibin Song | |||
| Huawei | Huawei | |||
| Email: haibin.song@huawei.com | Email: haibin.song@huawei.com | |||
| Jiang Xingfeng | Jiang Xingfeng | |||
| Huawei | Huawei | |||
| End of changes. 10 change blocks. | ||||
| 23 lines changed or deleted | 28 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||