COPS Usage for ODSI COPS Usage for ODSI Sorrento Networks Inc - - PowerPoint PPT Presentation

▶
cops usage for odsi cops usage for odsi
SMART_READER_LITE
LIVE PREVIEW

COPS Usage for ODSI COPS Usage for ODSI Sorrento Networks Inc - - PowerPoint PPT Presentation

Jul 29, 2023 101 likes •278 views

COPS Usage for ODSI COPS Usage for ODSI Sorrento Networks Inc Sorrento Networks Inc http://www.sorrentonet.com http://www.sorrentonet.com Nasir Ghani Nasir Ghani Zhensheng Zhang Zhensheng Zhang Leah Zhang Leah Zhang James Fu James Fu

slide-1
SLIDE 1

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

COPS Usage for ODSI COPS Usage for ODSI

Sorrento Networks Inc Sorrento Networks Inc

http://www.sorrentonet.com http://www.sorrentonet.com

Nasir Ghani Nasir Ghani Zhensheng Zhensheng Zhang Zhang Leah Zhang Leah Zhang James Fu James Fu

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

slide-2
SLIDE 2

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

Outline

Introduction ODSI Framework Overview COPS Usage for ODSI Conclusions References

slide-3
SLIDE 3

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

Introduction

COPS (Common Open Policy Service)

Automated policy provisioning, client/server model Generic signaling, applicable in various scenarios

ODSI (Optical Domain Service Interconnect)

Bridge between electronic and optical networks Automated optical circuit (bandwidth) provisioning

Proposal for optical networks

Re-use COPS for ODSI policy provisioning Parallel proposal in ODSI Forum

slide-4
SLIDE 4

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

ODSI Framework Overview

Architectural features

Trail requester, trail head, and trail tail entities Optical network controller (ONC, network device) Third-party signaling performs transactions E.g., create, destroy, modify, query, directory lookup User groups limit connectivity to members Service discovery, address registration via PPP

Current status

Functional/signaling/MIB specifications being updated New access control and accounting specification

slide-5
SLIDE 5

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

ODSI Framework Overview

Trail Head Optical Network Controller (ONC) Trail Requester User devices (e.g., IP routers, ATM switches, SONET/SDH cross-connects, Gigabit Ethernet nodes, etc.) source ODSI bandwidth action requests and comprise trail requester, head, and tail nodes ODSI control messages (TCP/IP transport) ODSI bandwidth (trail) action messages (create, destroy, modify, query). Request actions relayed to ONC via head and tail entities ONC responses to trail requester’s bandwidth actions (e.g., trail acknowledge, trail notification), sent back to trail requester entity. Trail Tail ONC validates request action and allocates capacity for bandwidth, resides inside optical network (e.g., co-located with optical networking device such as OXC/WRS, O-ADM). Point-to-point bandwidth connection (data)

slide-6
SLIDE 6

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

ODSI Framework Overview

Messages sourced by trail requester

Trail Create Request: Requests circuit setup, relayed to ONC Trail Modify Request: Requests circuit modify, relayed to ONC Trail Query: Check the status/parameters of an existing circuit Trail Destroy Request: Requests circuit teardown

Messages sourced by trail head

Trail Identity: Identifies requester of trail ID, serves as keepalive msg

Messages sourced by ONC

Trail Create Acknowledge: Indicates successful create request Trail Modify Acknowledge: Indicates successful modify request Trail Query Response: Returns status information for query request Trail Destroy Acknowledge: Indicates successful circuit teardown Trail Notification: Details unsuccessful create request

slide-7
SLIDE 7

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

COPS Usage for ODSI

Propose outsourcing model interworking

Most expeditious, allows simple interworking Similar model for other signaling protocols (RSVP)

ODSI PEP client

Inter-works with optical device’s ODSI entity Initiates PDP requests, relays ODSI messages Signaled client type (value 5)

ODSI PDP server

Policy decisions for “relayed” ODSI requests Logically “decoupled” from ONC entity

slide-8
SLIDE 8

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

COPS Usage for ODSI

PDP Server Policy enforcement point (sources policy requests for ODSI bandwidth actions) Policy decision point (optical network policy, fully “ODSI-aware”) LPDP local server Local policy decision point for localized policy decisions Optical Device COPS messages PEP Client ODSI Interface User Device ODSI Interface ODSI interface at client inter-networking device (e.g., router, ATM switch, or SONET cross-connect), sources ODSI bandwidth actions (i.e., trail create, destroy, query, modify) Optical network device (e.g., OXC, OADM, WRS) translates ODSI bandwidth actions into appropriate COPS messages TCP/IP transport ODSI messages TCP/IP transport

slide-9
SLIDE 9

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

COPS Usage for ODSI

PEP policy request generation/response processing

PEP generates initial COPS REQ message E.g., only create, destroy, modify, query transactions PEP resolves user groups, endpoint IP addresses ODSI request completion depends on PDP response PEP installs PDP decision, sends RPT updates

PDP policy request processing

PDP returns COPS DEC messages (install, remove) Decisions based on user group, IP addresses, SLAs E.g., expiry quotas, time-of-day limits Can issue synchronize, unsolicited DEC

slide-10
SLIDE 10

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

Conclusions

Optical network policy provisioning

Policy control crucial for advanced optical networks COPS yields comprehensive, extendible solution

COPS-ODSI interworking

Use COPS outsourcing (signaled client) model PEP client translates ODSI requests to PDP server “ODSI-aware” PDP server (message encapsulation)

Future work items

New PIB and associated rules definitions? What about a provisioned model?

slide-11
SLIDE 11

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

References

  • N. Ghani, Z. Zhang, L. Zhang, J. Fu, “COPS Usage for ODSI,” ODSI Coalition,

June 2000.

  • N. Ghani, Z. Zhang, L. Zhang, J. Fu, “COPS Usage for ODSI,” IETF Draft draft-

ghani-odsi-cops-00.txt, July 2000.

  • D. Durham, et al, “The COPS (Common Open Policy Service) Protocol,” IETF

Request for Comments (RFC) 2748, January 2000.

  • K. Chan, et al, "COPS Usage for Policy Provisioning," IETF Draft draft-ietf-rap-

pr-02.txt, March 2000.

  • G. Bernstein, et al, "Optical Domain Service Interconnect (ODSI) Functional

Specification," ODSI Coalition, March 2000.

  • G. Bernstein, et al, "Optical Domain Service Interconnect (ODSI) Signaling

Specification,” ODSI Coalition, April 2000.

  • G. Bernstein, et al, "ODSI Service Discovery and Address Registration," ODSI

Coalition, April 2000.

  • S. Herzog, et al, "COPS Usage for RSVP," IETF Request for Comments (RFC)

2749, January 2000.

  • D. Durham, et al, “COPS Usage for AAA," IETF Draft draft-durham-aaa-cops-

ext-00.txt, May 2000.

slide-12
SLIDE 12

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

Supplemental Slides

slide-13
SLIDE 13

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

COPS Usage for ODSI

Request (REQ) message

PEP only handles messages sourced by requester E.g., (trail) create, modify, query, destroy Message format:

<Request> ::= <Common Header> <Client Handle> <Context> [<ClientSI: Request ID, All objects in ODSI trail requester message>] [<LPDPDecision(s)>] [<Integrity>]

Modify request must include start times

<ClientSI>:: Request ID, All objects in ODSI trail requester message, <old starting time> <new starting time>

slide-14
SLIDE 14

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

COPS Usage for ODSI

Decision (DEC) message

PDP response to PEP “trail request” REQ msg Message format:

<Decision> ::= <Common Header> <Client Handle> <Decision> | <Error> [<Integrity>]

where

<Decision> ::= <Context><Decision: Command Code> <Decision: ClientSI data>

Server responses in command code field: Install (positive), remove (negative) Decision object explains negative decisions E.g., resource unavailable

slide-15
SLIDE 15

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

COPS Usage for ODSI

Report State (RPT) message

PEP reports decision outcomes or failure conditions Message format:

<Report State> ::= <Common Header> <Client Handle> <Report Type> <ClientSI: Request ID> [<Integrity>]

Synchronize State Request (SSQ) message

PDP sends SSQ message to “reset” state information Message format:

<Synchronize State Request> ::= <Common Header> <Client Handle> <ClientSI: SSQ Scope> [<Integrity>]

slide-16
SLIDE 16

48th IETF Meeting, Pittsburgh, PA, August 1st, 2000

COPS Usage for ODSI

Synchronize State Complete (SSC) message

ODSI-COPS PEP sends synch. complete to PDP Indicates all “state re-build” REQ messages sent Message format:

<Synchronize State Complete> ::= <Common Header> <Client Handle> <ClientSI: SSQ Scope> [<Integrity>]

Other COPS messages as per specification

OPN, CAT, KA, CC: For session control/maintenance DRQ: To withdraw outstanding REQ message E.g., if trail create acknowledge not yet issued