.ENT-AN1126-4.3 Application Note

Application Note JSON-RPCReleased

January 2018

Contents

1 Revision History.................................................................................................................................1

2 JSON-RPC...........................................................................................................................................22.1 Getting Started with JSON-RPC...........................................................................................................................2

2.1.1 The vson Tool.......................................................................................................................................32.2 JSON Interface Specifications.............................................................................................................................3

2.2.1 Use Cases.............................................................................................................................................42.2.2 Capabilities..........................................................................................................................................52.2.3 Microsemi JSON Interface Specification..............................................................................................5

2.3 Backward and Forward Compatibility...............................................................................................................102.3.1 What to Expect..................................................................................................................................102.3.2 Compatibility Implementation...........................................................................................................11

2.4 Integration Models...........................................................................................................................................122.4.1 HTTP(s) as Message Parsing...............................................................................................................122.4.2 Alternate Message Parsing Systems..................................................................................................12

iiVPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

Contents

Figures

Figure 1 • Client Library Auto-Generation Flow...................................................................................................................4Figure 2 • Document Auto-Generation Flow........................................................................................................................4Figure 3 • Management Interface Auto-Population Flow....................................................................................................5

iiiVPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

Figures

1 Revision History

The revision history describes the changes that were implemented in the document. The changes are listedby revision, starting with the most current publication.

Revision 1.1Revision 1.1 was published in January 2018. The following is a summary of changes in revision 1.1 of thisdocument.

• The vson Tool section was updated. For more information, see The vson Tool on page 3.

• The Capabilities section was updated. For more information, see Capabilities on page 5.

Revision 1.0Revision 1.0 was published in July 2016. It was the first publication of this document.

1VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

Revision History

2 JSON-RPC

This document introduces the JSON-RPC facilities added in theMicrosemi software. The intended audienceof this document is developers whowant to use the JSON-RPC interface formanaging theMicrosemi switchapplication running on a Microsemi switch device.

JSON-RPC is a protocol used for remote procedure calls. The messages exchanged in JSON-RPC are JSONencoded data structures. The JSON-RPC protocol has a server part and a client part. The client initiatescommunication by sending a request to the server, and the server processes the request to send back aresponse.

For JSON-RPC specification, see http://json-rpc.org/. For information about the general JSON specification,see http://json.org.

JSON-RPC provides a high-level management interface that is the functional equivalent of ICLI or SNMPwith the following additional properties:• Machine-friendly interface that can still be easily interpreted by humans.• Reliable connections-orientated communication provided by TCP and HTTP message encapsulation.• RPC-orientated protocol that fits into most programming languages.• Implementable in practically any language and needs only a very limited footprint in terms of program

memory and data memory.

Note:

JSON-RPC is not an end user interface (high level machine-friendly interface) intendedfor human interaction. Because of this, the intended audience of this document shouldbe familiar with the JSON- RPC technology. It is recommended that users not alreadyfamiliar with JSON and JSON-RPC 1.0 read the official standards.

2.1 Getting Started with JSON-RPCThe purpose of this section is to get started using JSON-RPC by verifying that the switch software of thedevice has JSON-RPC enabled and that it is functional.

JSON-RPC requires a message parsing protocol that is not part of the JSON-RPC standard but must beprovided by other technologies. The default JSON-RPC integration in Microsemi products is done using theHTTP protocol and the existing web server. For more information on options for message parsing, seeIntegration Models on page 12.

The curl application, which is available on most Linux/Unix and Windows systems, can be used to send aJSON-RPC request to the device over the HTTP protocol. The curl application is good for initial debugging,but one should not rely on it for designing applications. Almost all programming languages support eitherbuilt-in JSON-RPC or JSON-RPC library. The following is an example using curl.

curl http://admin:@target.ip.or.address/json_rpc -d \ '{"method":"ip.status.interface.ipv4.get", \ "params":[],"id":"0"}'

In this example, the curl application logs on to the device as the admin with no password.target.ip.or.address is a placeholder for the actual address and/json_rpc is the fixedUniformResource Locator (URL)where the JSON-RPC back-end server is integrated. The content of the-d argument

2VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

is the posted JSON-RPC request message, and the result printed on the screen. The following is an exampleof the result, with line breaks and indentations inserted to improve readability.

{ "id":"0", "error":null, "result":[ { "key":{ "VLAN 1", "10.99.10.12/24" }, "val":{ "broadcast":"10.99.10.255" } } ]}

2.1.1 The vson ToolCurl is good for the initial debugging, but it is very verbose and not so convenient to use when exploringthe Microsemi JSON-RPC command set. For this reason, we have developed a simple console-basedapplication that allows to call JSON-RPC methods easily and presents the result in a user-friendly way. Thistool is called vson, and it can be downloaded from GitHub using the following command.

$ git clone https://github.com/vtss/json-rpc-util.git

Then, go into the directory json-rpc-util and run the following command to get the possibleparameters.

$ ./vson --help

Also, run the following command.

$ ./vson -d <target-IP-address> -c update-spec

This downloads the json spec from the target and puts it in ~/.vtss-json-rpc.spec, which may beuseful to browse when reading this document. This is the result of the command.

$ ./vson -d <target-IP-address> -c call port.status.get “Gi 1/1”Calling port.status.get: Link: true Fdx: true Fiber: false Speed: speed1G SFPType: none SFPVendorName: SFPVendorPN: SFPVendorRev: LossOfSignal: true TxFault: true Present: false SFPVendorSN:

For more information about how to use the vson tool, see https://github.com/vtss/json-rpc-util.

2.2 JSON Interface SpecificationsTheMicrosemi JSON interface specification is used to document themethods available on the JSON interface.The Microsemi JSON interface specification is called json_spec. The json_spec is a JSON encodeddocument with a predefined schema.

This section is not about the specific interface specification generated on one of the Microsemi switchproducts, but rather an abstract specification of the Microsemi JSON interface specification.

3VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

The json_spec is normally distributed directly on the devices and it can be accessed in one of thefollowing ways:• Web—it can be downloaded from http://address.or.ip.of.device/json_spec

• JSON-RPC—the same specification can also be retrieved by calling thejsonRpc.status.introspection.generic.inventory.getmethod.

• JSON-RPC (target specific)—a variant of the same specification can be retrieved by calling thejsonRpc.status.introspection.specific.inventory.get method. The differenceis that this specification will only include attributes and methods available on the device where it wasgenerated.

The following section documents the use cases for json_spec and specifies how to interpret thejson_spec.

2.2.1 Use CasesThe following sections list some of the use cases considered during the development of json_spec.

2.2.1.1 Input to Auto-Generate a Client Library

Thejson_spec includes all the information needed to auto-generate a complete client library. The auto-generator determines the language to use for the client library, threading model, blocking/asynccommunication, and potential third-party libraries.

Figure 1 • Client Library Auto-Generation Flow

2.2.1.2 Input to Interface Documentation Generator

Thejson_spec includes all the interfaces needed to generate a complete set of interface documentation.The documentation generator determines the target format, style, and other details.

Figure 2 • Document Auto-Generation Flow

2.2.1.3 Auto-Populated Management Interface

The json_spec includes all information needed to build a complete management interface. This maybe used to build a CLI, Web GUI, or PC GUI, which uses the json_spec as introspection. The purpose ofthis is to avoid maintaining the set of commands in the Abstract Interface SW-Daemon (that is

4VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

the client part of json-rpc should use the json_spec to define what commands is supported) whenthe command set in MSCC-Switch evolves.

Figure 3 • Management Interface Auto-Population Flow

2.2.2 CapabilitiesA large part of the JSON interface is independent of the target used, but there are cases where this is notpossible. Typically, this is because the underlying hardware offers different facilities that need to be exposedto the user. In such cases, capabilities are used to inform what is available.

A capability is a getmethod that returns an object with a set of booleans. A given boolean specifieswhethera given capability is available.

Attributes and methods that depend on a capability provide a reference to the capability that they dependon. If the users of the JSON-RPC interface only use one target type, then it may be useful to generate thetarget specific version of the json_spec.

2.2.3 Microsemi JSON Interface SpecificationThis section provides a specification of the Microsemi JSON interface specification. Users who choose touse the json_spec to auto-generate any material from it should read this section carefully.

2.2.3.1 Top-Level Specification

The json_spec consists of an object containing three lists: types, groups, and methods.

{ "types":[ ... ],

"groups":[ ... ],

"methods":[ ... ]}

• The types list is the combined set of all named types used by all types and methods mentioned.• The groups list contains groups declarations that are referred to either by other groups or by

methods.• The methods list is the set of methods available.

2.2.3.2 Type Specification

A type specification is used to document the semantic of a given type. Types may be either named oranonymous. Named types are included in the types list, while anonymous types are declared where they

5VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

are used. A type has a base specification and a more elaborated specification that depends on the classfield. The following is an example of a base specification.

{ ["type-name":"<name-of-type-goes-here>"], "class":"<TypeSpecification|Enum|Struct|Array|Tuple>", ["description":"<description-goes-here>"], "json-encoding-type":"<Number|String|Boolean|Array|Object|null>", ...}

• type-name is the name of the type. It is optional because it is not used for anonymous types, butinstances in the types list will always include a name.When other types or methods refers to a type,they may use this name or include the type directly as an anonymous type.

• class is used to specify what family a given type belongs to. The supported type-classes are asfollows:◦ TypeSpecification is a terminal type,meaning that it is not a combinationof other predefined

types (for example, an IP address, which is encoded as a string in JSON, but in a programminginterface should be and represented as a dedicated type).

◦ Enum is a type, which is used to associate string notations to numbers. The JSON interface onlyuses the string notation, but programming interfaces may choose to use the number internally.

◦ Struct is an aggregation of other types (named or anonymous).◦ Array is a replication of a single type in zero or more instances.◦ Tuple is a sorted collection of zero or more different types.◦ description is used to document how the specific types must be interpreted and used.◦ json-encoding-type specifies how the given type is encoded in the JSON domain.

2.2.3.2.1 Type Specification

An object of class TypeSpecification uses the same schema as the base type. The following areTypeSpecification example objects.

Example IPv4:

This is the JSON specification of the type vtss_ipv4_t. In JSON messages it will be encoded as a stringusing the syntax defined in the description field. The client may choose to map this to an alternative typerepresenting a IPv4 address.

{ "type-name":"vtss_ipv4_t", "class":"TypeSpecification", "description":"Ipv4 address encoded as \"a.b.c.d\", where a-d is a base-10 human readable integer in the range [0-255]", "json-encoding-type":"String"}The following example is the JSON specification of the type vtss_ipv6_t.{ "type-name":"vtss_ipv6_t", "class":"TypeSpecification", "description":"An Ipv6 address represented as human readable test as specified in RFC5952", "json-encoding-type":"String"}

Example IPv6:

6VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

The following example is the JSON specification of the type vtss_ipv6_t.

The following example is the JSON specification of the type vtss_ipv6_t.{ "type-name":"vtss_ipv6_t", "class":"TypeSpecification", "description":"An Ipv6 address represented as human readable test as specified in RFC5952", "json-encoding-type":"String"}

2.2.3.2.2 Enum

An object of class Enum always has an elements field, which is a list of objects containing the fieldsname and values.

{ "type-name":"<name-of-type-goes-here>", "class":"Enum", "description":"<description-goes-here>", "json-encoding-type":"String", "elements":[ {"name":"<name-of-first-element>", "value":"<value-of-first-element>"}, {"name":"<name-of-second-element>", "value":"<value-of-second-element>"}, ... ]}

Example enum:

The following is an example of an Enum object.

{ "type-name":"vtss_appl_ece_rule_t", "class":"Enum", "description":"The ECE rule type.", "encoding-type":"String", "elements":[ {"name":"both", "value":"0"}, {"name":"rx", "value":"1"}, {"name":"tx", "value":"2"} ]}

2.2.3.2.3 Struct

A Struct object type has a list called elements, which always contains a set of element descriptor. Anelement descriptor object looks like:

{ "name":"<name-of-first-element>", "type":"<type-of-first-element>", ["description":"<description-of-element>",] ["depends-on-capability": "<reference-to-dependency-it-depends-on>"]}

Here is an explanation of each field in the element-descriptor:• name is the name of the element in the struct. When the type is encoded in JSON, the name is the

key-string used in the map.• type is either a reference to a type in the types list, or an anonymous type declared there. The

type referred to or the anonymous type defines what type to expect.

7VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

• description is an optional value that provides a description string for the given element.• depends-on-capability is an optional value that may provide a reference to a capability. If this

attribute is present in an element-descriptor, then it means that the given element is onlypresent if the capability is true. If the attribute is not present, then the given element is always present.An element that is not present (because its associated capability is false for a given target) is ignoredin a set operation and not included in a get operation.

The following example shows the structure of struct containing four elements, out of which two arealways present while the other two depend on capabilities. For the actual code, seevtss_appl_evc_ece_conf_t in the json_spec.

vtss_appl_evc_ece_conf_t in the json_spec.{ "type-name":"vtss_appl_evc_ece_conf_t", "class":"Struct", "description":"Example struct - not complete", "encoding-type":"Object", "elements":[ { "name":"NextId", "type":"uint32_t", "description":"The ID of the next ECE." }, { "name":"AdvLookup", "type":"vtss_bool_t", "description":"Enable advanced ingress lookup.", "depends-on-capability": "HasEceAdvLookup@vtss_appl_evc_capabilities_t" }, { "name":"UniPortList", "type":"vtss_port_list_stackable_t", "description":"List of UNI ports for the ECE." }, { "name":"SrcMac", "type":"vtss_mac_t", "description":"The source MAC address to match.", "depends-on-capability": "HasEceSrcMac@vtss_appl_evc_capabilities_t" } ]}

2.2.3.2.4 Array

An object of type Array has a field called type, which specifies the type of values in the array. The valueof type may either be a reference to a named type or a directly declared anonymous type. The followingis an example of an anonymous array type.

{ "class":"Array", "encoding-type": "Array", "type":"vtss_ifindex_t"}

8VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

2.2.3.2.5 Tuple

An object of type Tuple is very similar to an object of type Struct. The only difference is that the namefield in the element descriptor is optional for the array (not the tuple), and theencoding-type is alwaysan array. The following is an example of a tuple descriptor.

{"class": "Tuple", "encoding-type": "Array", "elements": [ { "name": "ifindex", "type": "vtss_ifindex_t" }, { "name": "prio", "type": "int32_t" } ]}

2.2.3.3 Group Specification

Methods and groups can be part of groups. A group can have a description that applies to everything storedin that group. To allow this, groups and methods may identify a group to which they belong. Such a groupis a reference to an object in the groups list. Objects in a group list have twomandatory fields-group-nameand description and an optional field called parent-group-name.

{ "group-name":"<name-of-group>", ["parent-group-name":"<name-of-parent-group>",] "description":"<description-of-group>"}The following code shows a complete example.{ "group-name":"acl.config.global.ace", "description":"The ACL ACE configuration table."},{ "group-name":"acl.config.global.ace.hardware", "parent-group-name":"acl.config.global.ace", "description":"Table of ACE hardware status."}

2.2.3.4 Method Specification

A method is defined using the following syntax.

{ "method-name":"<name-of-method>", ["group-name":"<name-of-group>",] ["description":"<description-of-method>",] ["notification":"<name-of-notification>",] ["depends-on-capability":"<reference-to-dependency-it-depends-on>",] "params":[ ... ], "results":[ ... ]}

• method-name—is the name of the method.

9VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

• name-of-group—is a reference to a group this method belongs to. The description of the groupshould be inherited as the description of the method.

• description—is a description of the method. This field is rarely used for methods, but insteadmost methods are documented through a group.

• depends-on-capability—if this attribute is present, then it means that this method is onlyimplemented on targets where the given capability evaluates to true. If this attribute is not present,then the method is always implemented (assuming the module is included on the target).

params and results fields are lists of argument specifications with following syntax:

{ "name":"<name-of-argument>", ["description":"<description-of-argument>",] "type":"<name-of-type>"}

The following in an example of a method.

{ "method-name":"ip.statistics.interface.ipv4.get", "params":[ { "name":"ifidx", "type":"vtss_ifindex_t" } ], "results":[ { "name":"stats", "description":"Interface statistics", "type":"vtss_appl_ip_if_status_ip_stat_t" } ]}

2.3 Backward and Forward CompatibilityThis section covers what is currently implemented and supported in the json_spec, but if necessary,this specification may be changed in future releases. If such changes take place, the changes should bebackward compatible. Backward and forward compatibility ensures that the JSON-RPC client continuescommunicating with the server when one of them is updated. Backward compatibility is needed when theserver (the Microsemi switch firmware) is updated and implements a newer Microsemi JSON specificationwhile the client continues to use an older version of theMicrosemi JSON specification. Forward compatibilityis needed when the client gets updated and now supports a newer version of the Microsemi JSONspecification than the one supported by the server.

Compatibility is a combined effort on the part of both the server and the client; theymust both be designedto accomplish this. This section describes the required server side setup. The client side must be set upproperly for the required client-server compatibility.

2.3.1 What to ExpectProviding 100% backward and forward compatibility on the entire JSON-RPC interface will make it verydifficult to fix bugs and introduce new features. Compatibility is provided on a best-effort basis to ensurethat the existing client functionality remains intact.

The following sections outline guidelines for implementing changes.

10VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

2.3.1.1 Major Rework

Major rework of a module may not be backward compatible. This is only likely to occur when a major newfeature is added. Such changes are documented in the release notes, and the new interface of the moduleis given a newname. In this case, all methodsmust be renamed. Doing so ensures that the change is noticedby the client. In some cases, both the new and the old interface may be accessible in a transition release.

2.3.1.2 Normal Evolution

Modules evolve with the addition of new features that are added by extending the existing structures withnew fields or methods. In such cases, the clients can be prepared for compatibility by ignoring unknownfields. The server ignores the client's attempt to configure a field in a struct that it does not recognize.If the client tries to call a method on the server that is not implemented, it will receive a “textitMethod notfound” error code -32601.

Compatibility should not be an issue if the client is prepared for such eventualities. Such changes can alwaysbe found by inspecting the differences between the previous and the current version of the MicrosemiJSON specification. Inspecting such differences can be done by using the vtss-json-spec-diff tool, which isavailable along with the vson tool.

2.3.1.3 Bug Fixes

Bugs can typically be fixed without changing the JSON-RPC interfaces, and compatibility should not be anissue. Any necessary changes get categorized as part of normal evolution.

2.3.2 Compatibility ImplementationThe following sections describe the implementation to maintain compatibility, given that target systemshave no knowledge of future versions or different versions of clients thatwill access the JSON-RPC interface.

2.3.2.1 Methods

The target system implements a set of methods corresponding to the current version of the MicrosemiJSON specification. If a client tries to call a method that does not exist, the server responds with a “Methodnot found” error message. The client needs to recognize unsupported method errors and adapt to thesituation.

Typically, this is a forward compatibility problem that occurs when the client is newer than the server. Inmost cases, the existing methods are retained and new methods are added unless a major rework isimplemented. It is up to the client to handle this scenario properly.

2.3.2.2 Structures (JSON Objects)

In the JSON-RPC server implementation, all fields in structures are considered optional. This means thatthe server ignores a field in a struct that it does not recognize. If the server is missing assignments ofone or more fields in a set/add request, then it uses default values.

For set methods, the default values are provided as follows:• Performing a get request• Overwriting the values provided by the get request with the new values from the set request• Calling the C management method to apply the request. This patching is only done at the first level. If

nested structures are exposed, this process is not applied recursively.

For add or set-in-write-only-context, the process is almost the same, except an internaldefaultsmethods is used in place of the getmethod.

11VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

2.4 Integration ModelsJSON-RPC is only a protocol for allowing remote procedure calls. It does not definemessage parsing facilitiesand assumes that this is done by other means. HTTP(s) is the most commonly used message exchangeprotocol used along with JSON-RPC, but it is not always the right choice.

Microsemi software already includes support (enabled by default) for running JSON-RPC over HTTP so thatusers can focus on the client part.

HTTP(s) may not always be the right message exchange protocol. This topic provides guidance on when touse HTTP(s) as message exchange protocol. It also mentions alternatives to using HTTP(s) for messageexchange.

2.4.1 HTTP(s) as Message ParsingTo use the JSON-RPC server with HTTP(s) as a message exchange protocol, just post the JSON-RPC requestto the /json_rpc address, and wait for the response.

Note:

HTTP client should always use the keep-alive property to allow reuse of the same TCPconnection for a number of commands.

Running JSON-RPC over HTTP(s) is a ideal solution if all of the following criteria are met. This is typically thecase when using JSON-RPC for remote management systems or other loosely coupled systems.• The RPC communication must go through a TCP/IP connection.• Reasons for such criteria could be that the RPC communicationmust be able to go through a IP network,

or that the guarantees provided by TCP are needed.• The security facilities provided by HTTP(s) match the criteria required for the RPC communication.• Even though HTTP uses basic authentications without any encryption, HTTPS can be enabled on the

target system. This will allow JSON-RPC to run over HTTPS and benefit from the security attributesprovided by HTTPS.

Running JSON-RPC over HTTP(s) should not be considered as a possibility if any of the following propertiesare needed.• RPC communication must work when the target has no IP address.• Security facilities provided by HTTP(s) are not good enough.• The overhead of IP + TCP + HTTP is not acceptable.• Management traffic must not go through the normal Ethernet connectivity.

If any of these properties are needed, then the JSON-RPC over HTTP(s) can not be used. In this case, it ispossible to provide an alternative message exchange protocol. For more information about alternativemessage exchange protocol, see Alternate Message Parsing Systems on page 12.

2.4.2 Alternate Message Parsing SystemsWhen JSON-RPC over HTTP(s) is not an optimal solution, it is possible to integrate an alternative messageexchange facility with the desired characteristics.

To do this, an alternative message exchange facility must be developed and the JSON-RPC server must beintegrated. Integrating the JSON-RPC back-end server should be easy when the message exchange is inplace and working.

The integration of JSON-RPC over HTTP(s) can be used as an example when enrolling JSON-RPC on top ofother facilities. This integration is located in vtss_appl/json_rpc/json_rpc_platform.cxx

12VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

in the json_http_handler function. Integrating the JSON-RPC back-end server with a new messageexchange facility is accomplished by calling the following C++ method.

namespace vtss {namespace expose {namespace json {vtss::json::Result::Code RootNode::process(str input, ostreamBuf &out);} // namespace json} // namespace expose} // namespace vtss

The methods must be called on the JSON_RPC_ROOT instance, which is a static variable invtss_appl/json_rpc/json_rpc_platform.cxx. The method is thread safe and may be calledfrom a multi-threaded application without taking any precautions.

The input parameter is a reference to the incoming JSON-RPC request, which must be processed. TheJSON-RPC response is written into the out buffer stream.

Candidates for using this facility are dual CPU systems where the message passing is accomplished usingdedicated channels, or tightly coupled systems where the requirement of a functional TCP/IP connectionis not possible (for example, the device is not allowed to have a configured IP).

13VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

JSON-RPC

Microsemi makes no warranty, representation, or guarantee regarding the information containedherein or the suitability of its products and services for any particular purpose, nor doesMicrosemiassume any liability whatsoever arising out of the application or use of any product or circuit. Theproducts sold hereunder and any other products sold by Microsemi have been subject to limitedtesting and should not be used in conjunctionwithmission-critical equipment or applications. Anyperformance specifications are believed to be reliable but are not verified, and Buyermust conductand complete all performance and other testing of the products, alone and together with, orinstalled in, any end-products. Buyer shall not rely on any data and performance specifications orparameters provided by Microsemi. It is the Buyer's responsibility to independently determinesuitability of any products and to test and verify the same. The information provided byMicrosemihereunder is provided "as is, where is" and with all faults, and the entire risk associated with suchinformation is entirely with the Buyer. Microsemi does not grant, explicitly or implicitly, to anyparty any patent rights, licenses, or any other IP rights, whether with regard to such informationitself or anything described by such information. Information provided in this document isproprietary toMicrosemi, andMicrosemi reserves the right tomake any changes to the informationin this document or to any products and services at any time without notice.

Microsemi HeadquartersOne Enterprise, Aliso Viejo,CA 92656 USA

Within the USA: +1 (800) 713-4113Outside the USA: +1 (949) 380-6100Sales: +1 (949) 380-6136Fax: +1 (949) 215-4996Email: sales.support@microsemi.comwww.microsemi.com

© 2019 Microsemi. All rights reserved.Microsemi and the Microsemi logo aretrademarks of Microsemi Corporation. Allother trademarks and service marks are theproperty of their respective owners.

Microsemi, awholly owned subsidiary ofMicrochip Technology Inc. (Nasdaq:MCHP),offers a comprehensive portfolio of semiconductor and system solutions foraerospace&defense, communications, data center and industrialmarkets. Productsinclude high-performance and radiation-hardened analog mixed-signal integratedcircuits, FPGAs, SoCs and ASICs; power management products; timing andsynchronization devices and precise time solutions, setting the world's standardfor time; voice processing devices; RF solutions; discrete components; enterprisestorage and communication solutions; security technologies and scalable anti-tamperproducts; Ethernet solutions; Power-over-Ethernet ICs and midspans; as well ascustom design capabilities and services. Microsemi is headquartered in Aliso Viejo,California, and has approximately 4,800 employees globally. Learn more atwww.microsemi.com.

VPPD-04260

14VPPD-04260 ENT-AN1126-4.3 Application Note Revision 1.1

Legal