Transcript NSI WSDL update

OGF NSI Protocol
Protocol status and discussion
John MacAuley
SURFnet
[email protected]
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
Saturday, July 16 2011
NSI Protocol Status
• Initial draft versions of NSI WSDL received good
feedback and proposed changes were
incorporated.
• Development teams have started implementing
NSA agents using the NSI WSDL which has
resulted in additional feedback.
• Urgency around closing on a version of the WSDL
so development teams can avoid costly churn.
• Last key item to include is digital signing of NSI
message using WS-SecurityPolicy.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
2
NSI Transport Requirements
• Guaranteed delivery of NSI messages
• The transport layer must guarantee delivery of NSI messages, or inform an
NSA if delivery of a message did not occur.
• Message request/response decoupling
• Large separation in time of request from confirmed/failed response
message.
• Message confidentiality
• Encryption of NSI messages during transport to avoid prying eyes.
• Authentication
• Establishment of trust between a pair of peer NSA.
• Message integrity and authenticity
• Verifying that an NSI message has not been tampered with in transit, and
that the message is from the expected NSA.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
3
NSI Operation Set
1. Reservation
• Make a request to reserve network resources for a connection between two STP’s constrained by
certain service parameters.
2. Provision
• Provider NSA has been given permission to setup a reservation (associated with a previous
reservation message) on the Requester NSA's behalf but subject to the constraints of the
requested service.
3. Release
• Provider NSA should release the provisioned resources without removing the reservation.
4. Terminate
• Provider NSA should release the provisioned resources and terminate the reservation.
5. Query
• Mechanism for either NSA to query the other NSA for a set of connection service instances
between the RA-PA pair. This message can be used as a status polling mechanism.
6. ForcedEnd
• An autonomous message issued from a Provider NSA when an existing reservation is
administratively terminated before the reservation's scheduled end-time.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
4
Generic NSI Message Set
•
Request
• A Requestor NSA issues an operation request message such as
"reservationRequest" to the Provider NSA. The Requestor NSA can expect
an response to the request at some point in the future.
• Confirmed
• A Provider NSA sends this positive operation response message (such as
"reservationConfirmed") to the Requester NSA that issued the original
request message ("reservationRequest").
• Failed
• A Provider NSA sends this negative operation response message (such as
"reservationFailed") to the Requester NSA that issued the original request
message ("reservationRequest").
• ForceEnd is an exception
• It is modeled as an unconfirmed request from a Provider NSA to a
Requestor NSA.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
5
The SOAP Stack
NSI Protocol
XML
SOAP
HTTP
TLS
TCP/IP
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
6
Providers and Requestors
• Provider Entity
• A web service is provided by a “provider
Consumes
entity” and exposed through a Service
Endpoint Interface (SEI).
• A provider entity publishes its service
through a WSDL document-based
description, and provides a Service
WSDL
Endpoint Reference (EPR).
Interact
SEI
• Requestor Entity
• A web service is used by a “requestor
entity.”
• A requestor entity uses the web service’s
WSDL description and EPR to interact
with the web service.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
Requestor
Entity
7
Publishes
Provider
Entity
Service Description
• A provider entity formally describes a web service through a
WSDL 1.1 document
• Specifies the service interface (messages, operations, types).
• Includes the endpoint HTTP URI address of the provider agent.
• A WSDL document is only a syntactic description of the
service, and is void of interface semantics.
• Interface semantics are defined either implicitly or explicitly
through a verbal or written exchange between a provider
entity and a requestor entity.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
8
SOAP Basic Request/Response
• Web services support a basic request/response messaging
model using the HTTP/SOAP binding:
•
•
•
•
HTTP POST carries the request operation.
HTTP response to POST carries result of the operation.
HTTP socket blocks until result it returned (synchronous).
Standard design pattern utilizes multiple threads to issue concurrent
operations.
HTTP POST (SOAP Request)
Provider
Entity
Requestor
Entity
200 OK (SOAP Response)
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
9
Asynchronous Messaging
• NSI protocol requires response messages (confirmed,
failed) be delivered to a Requestor NSA at an arbitrary
point in the future
• This requirement leads us towards an asynchronous messaging
architecture where we decouple response delivery from the request.
• Basic HTTP/SOAP binding uses a synchronous request/response
model.
• We have implemented a simple asynchronous messaging
scheme using multiple request/response interactions
• Keeping it simple - use basic point-to-point HTTP exchanges.
• Specify single HTTP/SOAP profile for NSA interoperability.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
10
Standard NSI message pattern
• NSI protocol requires both requestor and provider entities
to maintain SOAP endpoints:
HTTP POST (reservation)
Requestor
NSA
A
Provider
NSA
200 OK (reservationResponse)
.
.
.
HTTP POST (reservationConfirmed)
Requestor
NSA
Provider
NSA
B
200 OK (reservationConfirmedResponse)
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
11
NSI transport mechanism
• SOAP over HTTPS (HTTP over TLS) will be the primary
message transport mechanism providing encryption, data
integrity, and certificate-based authentication between peer
NSA.
• Stream-based transport will provide data segmentation at
the lower layers of the TCP/IP stack.
• HTTPS can be used for transferring large datasets through
its chunk support.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
12
WSDL Discussion
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
13
Separation of WSDL service definitions
• Suggestion made to segment SOAP bindings into separate
provider and requestor definitions.
• Provider will contain SOAP endpoint for:
• reservation, provision, release, terminate, and query
• Requestor will contain SOAP endpoint for:
•
•
•
•
•
•
reservationConfirmed, reservationFailed
provisionConfirmed, provisionFailed
releaseConfirmed, releaseFailed
terminateConfirmed, terminateFailed
queryConfirmed, queryFailed
forcedEnd
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
14
Local schema importing
• NSI types XSD imports SAML attribute definitions for our
security attributes:
http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion2.0.xsd
• This in turn imports the following schemas:
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsigcore-schema.xsd
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xencschema.xsd
• Dynamic downloading of these schemas have been
causing development issues due to web site issues.
• We would like to make these local imports and distribute
the three additional schema files with the NSI schema.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
15
Message integrity and authenticity
• We have the transport requirements to verify an NSI
message has not been tampered with in transit, and that
the message is from the expected NSA.
• To solve this requirement we would like to digitally sign the
NSI message using WS-SecurityPolicy SOAP extensions.
• Attach a wsPolicy item to each operation/message
• Define the policies we wanted in a separate wsdl and then include it
in the service bindings.
• Modify the service bindings to reference appropriate policies.
• Utilize x509 AsymmetricBinding policy
• Send a signed timestamp and the signing certificate with each
message.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
16
WSDL Definitions – output messages
•
Current request/response transport message exchange pattern is to send
SOAP request message in an HTTP POST and return a response
(acknowledge) in the POST result.
•
The output message contains no data except the element tag so people have
questioned if it should be removed?
Transport will still know of the successful send since the HTTP 200 response is
always returned, but other transports may not. Note: Need to check asynch API
binding.
SOAP implementation will wait for the result do to the SOAP fault definition.
•
•
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
17
WSDL versioning
• XSD versioning typically managed through namespace
URL
http://schemas.ogf.org/nsi/2011/07/connection/types
• WSDL versioning can be managed through namespace
URL, however, there are alternative solutions that allow for
multiple versions to exist simultaneously in a single
document
.
.
.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
18
Schema Discussion Items
• transactionId
• Models a single request/confirm/failed interaction to correlate response
messages to the original request.
• Suggestion received to rename to requestId or correltationId.
• Should this be moved from the transport specific WSDL definition to the NSI
XSD definition to make it part of the NSI message definitions?
• There have also been arguments to remove this identifier.
• ReservationRequestType
• We currently have ReservationRequestType defined in both the interface
and types name space.
• Java will generate types with the same name in two separate packages.
• Should we rename one of the types to make all types unique throughout all
schema files?
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
19
Schema Discussion Items
• pathObject
•
•
Request to rename pathObject to path within the schema.
Request to move pathObject out of ServiceParameters and into reservation message
body.
•
Should be move directionality into the path object?
• Query operation
•
•
Currently support query by a list of globalReservationId, connectionId, or state
machine state.
Should we add the ability to retrieve all connectionId associated with a requestorNSA
to help in fault recovery?
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
20
Behavioral issues
• Reservation record lifetime
• How long will a reservation record exist in the NSA after reaching a
terminated state?
• Should a query be able to access schedule information after it has
reached terminated?
• Should we make a statement in the specification requirements or
leave this to implementation agreements?
• Reservation persistency
• To perform useful error recovery and NSA needs to persist
reservation information (parent and children connectionId mapping
at a minimum) to permit recovery after a failure (such as a server
restart).
• Do we want to formalize any error recovery requirements or leave
them to implementation agreements?
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
21
Meeting Decisions
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
22
Actions (1)
• Segment service bindings into requestor and provider messages sets
• Will help with code modularity and provides the proper endpoint definition
for RA and PA.
• Modify the XSD definitions to do local imports and copy the needed
external XSD locally to package with NSI definitions.
• transactionId
• Rename transactionId to correlationId and consider moving into XSD
message payload.
• correlationId will remain a UUID since a sequence number will not behave
in any useful way with differing durations on operations. We can get back a
confirm for a later operation before the earlier.
• WSDL output messages
• Leave response output messages in WSDL but rename to a generic
acknowledge.
• Add correlationId to help asynchronous JAX-WS bindings.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
23
Actions (2)
• Change globalReservationId to be an xsd:anyURI type to hold an OGF
URN
•
Meeting notes indicates change to mandatory but can be null.
• Remove version tags from interface and service definitions
•
Will use namespace versioning until such a time as we can determine our needs for
WSDL versioning.
• Remove connectionState from generic confirmed and reservation
confirmed message since the state should be implied.
• Rename one of the ReservationRequestType definitions to make all
types unique across all schema definitions.
• NSA identifiers are now defined as xsd:anyURI to hold an OGF URN.
• STP definition is now changed to be a xsd:anyURI to hold an OGF
URN.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
24
Actions (3)
• Query operation
• Remove the query option for search based on connection state.
• Do we need to model user information in the the query
results?
• At the moment security parameters are passed in the main message
payload and not the reservation information. Should we also return security
information such as the user who created the schedule?
• Do we then need to declare security data must be persistently stored with
the reservation?
• Add WS-SecurityPolicy definitions to the WSDL for digital signature on
SOAP messages
• Can this be optional?
• Start a discussion on error messages and how they will be modeled in
the failed message structure.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
25
Next steps?
• Can we do a simple topology discovery interface?
• Should we provide a simple topology WSDL to retrieve the topology
information needed for the demo instead of relying on a text file?
• It is more complicated but could be an initial proof point for NML.
• Perhaps after Rio GLIF meeting?
• Dynamic service discovery
• WS-Inspection is a web service specification for "discovery documents"
developed in a joint effort by Microsoft and IBM.
• WS-Inspection lists groups of web services and their endpoints in an XML
format.
• We could add a simple WSDL interface on each NSA to permit a peer NSA
to discover supported interfaces and versions.
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
26
The End
OGF32 – Salt Lake City
NSI-WG: Network Service Interface working group
27