요약

  • OpenFlow는 일부 제어 메시지의 재정렬을 허용합니다. Barrier Reply는 동일한 연결에서 이전 메시지들이 나중 메시지가 시작되기 전에, 해당 응답이나 오류까지 포함해 완전히 처리되었음을 말합니다.
  • 규격은 별도로, 완전히 처리된 Packet-Out조차 스위치를 떠나지 못할 수 있다고 경고합니다. 따라서 배리어는 의도한 규칙이 매치에 승리했음도, 엔드포인트가 패킷을 받았음도 증명하지 않습니다.
  • Nick McKeown의 중요성은 구조적이고 협업적인 것입니다. OpenFlow는 컨트롤러–스위치 경계를 명확히 만들었습니다. 운영자는 하나의 확인 신호를 배포 판정으로 승격시키는 대신, 순서·상태·매치·이그레스·경로·결과 영수증을 결합함으로써 그 정밀성을 지켜야 합니다.

결과는 더러운데 확인은 깨끗한 경우

컨트롤러 로그가 깔끔하게 끝나는 배포를 상상해 보십시오. FlowMod 전송, Barrier Request 전송, Barrier Reply 수신. 대시보드가 초록으로 바뀝니다. 1분 뒤 서비스 데스크에서 목적지에 도달할 수 없다는 보고가 옵니다.

두 사실 모두에 맞는 설명은 여러 가지입니다. FlowMod가 의도한 스위치에는 갔지만 더 높은 우선순위 규칙이 그것을 가릴 수 있습니다. 잘못된 테이블에 있거나 잘못된 마스크를 가질 수 있습니다. 그 지시문이 활성 버킷이 다른 곳을 가리키는 그룹이나 폐기하는 미터를 통해 트래픽을 보낼 수 있습니다. 출력 포트가 차단되었을 수 있습니다. 혼잡이나 QoS가 프로토콜 처리 후 Packet-Out을 폐기할 수 있습니다. 첫 스위치가 컨트롤러가 요청한 대로 정확히 수행했더라도 다운스트림 장치가 실패할 수 있습니다.

이 경우들에서 결함이 있는 것은 배리어가 아니라, 그것에 붙은 판정입니다.

OpenFlow 1.3.5는 배리어에 좁은 역할을 부여합니다. 배리어가 없으면 스위치는 성능 향상을 위해 메시지를 재정렬할 수 있습니다. 하나의 연결에서, Barrier Request 이전의 메시지들은—결과적인 응답이나 오류를 포함해—완전히 처리되어야 하고, 그다음 배리어가 처리·응답되며, 그 이후에야 나중 메시지가 시작될 수 있습니다. 규격의 예제들은 의존성 문제입니다: 그것을 사용하는 플로우를 설치하기 전에 그룹을 생성하기; 그것을 통해 Packet-Out을 보내기 전에 포트를 변경하기; 테이블을 통해 패킷을 보내기 전에 플로우를 설치하기.

이것은 가치 있는 순서 증거입니다. 그러나 네트워크 트랜잭션이나, 매치 영수증이나, 전달 영수증이 아닙니다.

McKeown이 보이게 만든 인터페이스

2008년 OpenFlow 논문은 Nick McKeown이 Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, Jonathan Turner와 함께 썼습니다. 그 실용적 타협은 소박하면서도 결과가 컸습니다. 실험자의 컨트롤러가 실제 스위치의 플로우 테이블에 항목을 추가·제거하되, 평범한 포워딩은 빠르게 유지되도록 하는 것입니다. 논문의 Amy-OSPF 예제에서 컨트롤러가 경로를 선택하고 각 스위치를 프로그래밍하며, 이후 패킷들은 테이블이 처리합니다.

McKeown은 OpenFlow와 소프트웨어 정의 네트워킹의 공동 기원자로 묘사하는 것이 타당하며, 프로토콜이나 이후 배리어 메커니즘의 단독 발명가가 아닙니다. 배포 팀과 Open Networking Foundation이 수많은 기여를 통해 규격을 발전시켰습니다. 이 글에서 그의 관련성은, 그 구조가 결정과 실행을 충분히 명확히 분리해서 경계의 영수증들에 이름을 붙일 수 있게 했다는 점입니다.

2014년에 발표된 배포 역사는 운영 피드백이 OpenFlow 0.9에 Barrier 명령을 도입하는 데 도움이 되었다고 기록합니다. 또한 가변적인 플로우 설정 지연, 약한 스위치 CPU, 인밴드 제어 문제, 그리고 왕복 시간·CPU 부하·설정률·애플리케이션 측정과 제어 트레이스를 상관 분석한 진단을 기록합니다. 배리어는 실제 불확실성에서 나왔으며, 다른 관찰의 필요를 없애려고 설계된 것이 아니었습니다.

“완전히 처리됨”은 선 앞에서 멈춘다

OpenFlow 1.3.5는 이 한계를 이례적으로 명확히 밝힙니다. Packet-Out을 완전히 처리하는 것이 패킷이 스위치를 빠져나가는 것을 보장하지 않습니다. 혼잡, QoS, 차단된 포트 또는 유효하지 않은 포트는 OpenFlow 액션이 처리된 뒤의 무음 폐기를 일으킬 수 있습니다. 컨트롤러로 향하는 트래픽 역시 폴리싱이나 혼잡 하에서 예상된 Packet-In 없이 손실될 수 있습니다.

플로우 파이프라인은 더 많은 경계를 더합니다. 플로우 항목은 매치 필드, 우선순위, 카운터, 지시문, 타임아웃, 쿠키로 이루어집니다. 처리는 테이블 0에서 시작해 다른 테이블로 이어질 수 있습니다. 테이블 내에서는 가장 높은 우선순위의 매치 항목이 이기며, 지시문은 메타데이터나 액션 세트를 바꾸고, 그룹을 호출하고, 미터를 통과시키고, 이그레스 처리를 선택할 수 있습니다. 따라서 의도한 쿠키를 다시 읽어오는 것은 배리어를 보는 것보다 강하지만, 대상 패킷이 그 항목을 선택했음을 증명하는 것보다는 약합니다. 카운터 증가는 관찰 지점에서의 매치를 증명할 뿐, 다음 링크 너머의 생존은 증명하지 않습니다.

연결 범위도 또 다른 함정입니다. 규격은 OpenFlow 연결 간에는 동기화가 없다고 말합니다. 메인 연결의 Barrier Request는 보조 연결로 보낸 의존 작업에 대해 아무것도 말하지 않습니다. 장애 조치나 재접속 후 컨트롤러는 새 채널을 기존 채널의 연속으로 취급하는 대신, 스위치의 보존된 상태와 자신의 역할을 확립해야 합니다.

적합성 시험은 영수증을 분리해 둔다

ONF 1.3.4 Basic Single Table 적합성 규격에는 유익한 분리가 있습니다. 그 배리어 시험은 최대 10,000개의 플로우를 추가·삭제하고, Barrier Request를 보내고, 하나의 제어 연결에서 요청된 Flow-Removed 메시지들 이후에만 Barrier Reply를 기대합니다. 근처의 Packet-Out 시험은 데이터 플레인 연결을 사용해 패킷이 실제로 수신되는지 확인합니다.

두 시험이 존재하는 이유는 두 사실을 확립하기 위해서입니다. 운영 콘솔에서 이들의 상태 표시등을 합쳐도 의미는 합쳐지지 않습니다.

OpenFlow 1.5.1의 번들은 사슬의 다른 부분을 강화합니다. 컨트롤러는 여러 변경을 스테이징해 함께 커밋할 수 있고, 커밋 시점에 수정이 실패하면 그 번들은 적용되어서는 안 됩니다. 지원은 선택 사항이며 장치 능력에 제약을 받습니다. 성공한 번들은 느슨한 FlowMod 연속보다 강한 구성 증거이지만, 여전히 어떤 실제 헤더가 어떤 테이블 매치에서 이겼는지, 원격 서비스가 트랜잭션을 완료했는지는 알려주지 않습니다.

VeriFlow는 또 다른 층을 다룹니다. 규칙 변경을 가로채 포워딩 플레인 모델 위에서 네트워크 전역 불변식을 검사함으로써, 복잡한 컨트롤러 코드에 대한 신뢰 의존을 줄입니다. 이는 업데이트가 장치에 도달하기 전에 루프, 블랙홀, 정책 위반을 잡을 수 있습니다. 그러나 올바른 모델은 케이블 위의 광전 센서가 아니며, 애플리케이션 영수증도 아닙니다. 모델 검증과 물리적 결과 텔레메트리는 서로를 대행해서는 안 되고 보강해야 합니다.

더 큰 초록 불이 아니라 영수증 사슬을 만들어라

방어 가능한 배포는 여덟 개의 연결된 영수증으로 표현될 수 있습니다:

  1. 의도:버전 관리된 정책과 원하는 규칙 집합이 알려져 있다.
  2. 전송:컨트롤러가 올바른 Datapath ID, 역할, 연결로 통신했다.
  3. 순서:이전 응답과 오류가 모두 정산된 후 그 연결에 Barrier Reply가 도착했다.
  4. 상태:펜스 이후에 테이블, 우선순위, 매치 마스크, 쿠키, 그룹, 미터, 포트 상태가 다시 읽혔다.
  5. 매치:실제 트래픽을 대표하는 헤더를 가진 제어된 패킷이 예상 카운터를 변화시켰다.
  6. 이그레스:포트나 큐 텔레메트리가 로컬 폐기 조건 없이 의도한 출력을 보였다.
  7. 경로:다운스트림 관찰 또는 능동 프로브가 실제로 선택된 경로를 확인했다.
  8. 결과:엔드포인트 또는 애플리케이션이 의도한 트랜잭션을 기록했다.

어떤 항목도 다음 항목의 의미를 물려받지 않습니다. 오류 수 0은 상태 재독입이 아닙니다. 상태 일치는 패킷 매치가 아닙니다. 패킷 매치는 이그레스가 아닙니다. 이그레스는 도착이 아닙니다. 비대표성 합성 출처의 HTTP 성공은 모든 실제 트래픽 클래스에 대한 증명이 아닙니다.

개념만큼 식별자도 세심하게 결합되어야 합니다. 변경 버전, 스위치 신원, 연결 세대, OpenFlow 트랜잭션 식별자, 쿠키, 프로브 헤더, 시간 창을 함께 유지하십시오. 그렇지 않으면 서로 다른 시도의 증거가 우연히 설득력 있지만 허구적인 성공 이야기를 형성할 수 있습니다.

출처